3

I'm using curl to request a URL that redirects to a different URL using a Location: line like:

Location:/path/to/resource#name

As I understand it, that line in the redirect response is invalid per the HTTP specifications, so the overall curl call understandably fails (in this case, with a 400 response code). However, requesting the URL with wget or a web browser successfully renders the page (I assume through heuristics that fill in the absolute path or remove the anchor tag before the redirect).

Is there anything I can do to make curl do the same (do what is necessary to successfully follow the redirect, even if it is "officially" malformed)?

Edit: Some more details. The final response code is 400 (not 404 or something else). When I do a HEAD request (with curl -I -L), I get a 302 Found (with Location: /Error) that redirects to a 500 Server Error. However, if I do a regular request (without the -I option but with the -L option), I get a http_code (in curl's --write-out) of 400. So it seems like HEAD requests in this case function differently than standard GETs.

1
  • You say that the "overall curl call" results in a "400 response code". Do you mean an actual 400 (bad request), or some other 4** response code such as 404 (Not found)? I'm beginning to think that everything is working as it should be but the page you are re-directing to doesn't exist (404), is forbidden (403) or similar. What response code is returned when you use curl to request the page you are redirected to directly?
    – Tom Hudson
    Jan 17, 2012 at 1:52

2 Answers 2

6

As I understand it, curl doesn't follow Location headers by default.

You can enable such behaviour by using the -L or --location switch. Like so:

tom@slappy:~▶ curl -I -L http://shell/redirect.php     
HTTP/1.1 302 Found
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
X-Powered-By: PHP/5.3.5-1ubuntu7.2
Location: /target.html#someAnchor
Content-Type: text/html

HTTP/1.1 200 OK
Date: Tue, 17 Jan 2012 00:13:54 GMT
Server: Apache/2.2.17 (Ubuntu)
Last-Modified: Tue, 17 Jan 2012 00:10:37 GMT
Accept-Ranges: bytes
Content-Length: 7
Content-Type: text/html

Note: -I is only used to show the headers rather than page content. I tested this using curl 7.21.6 running on Ubuntu.

3
  • Sorry for the vagueness, I am using -L to follow redirects. The problem is that the malformed Location: line makes the curl call fail, while wget and browsers succeed. Your example does seem to work though, strange...
    – jrdioko
    Jan 17, 2012 at 0:46
  • Can you post the complete headers for the request and response? (Just the whole thing with -I really) for comparison?
    – Tom Hudson
    Jan 17, 2012 at 1:12
  • Edited question to add more details.
    – jrdioko
    Jan 17, 2012 at 17:40
3

I discovered this particular issue occurs with curl 7.15.5 but works fine with curl 7.21.0. So there must have been a bug fix or feature implemented in between that solves it. If anyone knows exactly what patch or change addressed this, that would be appreciated!

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .