Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

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.

share|improve this question
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 '12 at 1:52

2 Answers

up vote 2 down vote

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.

share|improve this answer
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 '12 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 '12 at 1:12
Edited question to add more details. – jrdioko Jan 17 '12 at 17:40
up vote 0 down vote accepted

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!

share|improve this answer
1  
Yes, this behavior was recently fixed in curl - daniel.haxx.se/blog/2011/12/31/top-3-curl-bugs-in-2011 – andol Jan 18 '12 at 20:01
@andol: Perfect, thanks! – jrdioko Jan 18 '12 at 20:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.