Using curl to request URL that redirects to relative URL with anchor tag

Question

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.

Answer 1

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.

Answer 2

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!