HEAD is converted to a GET when following a 302 redirect #24

joeyh opened this Issue Feb 11, 2012 · 2 comments


None yet

3 participants


I'm using HEAD to check the size of a very large url before downloading it, so it's surprising that when there's a 302 redirect, it's followed using GET.

Haskell member

Sorry for the delay in looking at this.

On investigation, it turns out that changing requests to a GET is deliberate, and that while 302 is not technically supposed to change the request type, most clients do treat it that way in practice. 307 was apparently created to provide a "proper" temporary URL redirection mechanism.

The behaviour seems mostly intended for reacting to POST and PUT/DELETE requests. I can't see an actual use for turning a HEAD into a GET, so perhaps we should pass HEAD through unchanged?

@kaostao kaostao pushed a commit to kaostao/git-annex that referenced this issue Mar 28, 2014
@joeyh joeyh work around Network.Browser bug that converts a HEAD to a GET when fo…
…llowing a redirect

The code explicitly switches from HEAD to GET for most redirects.
Possibly because someone misread a spec (which does require switching from
POST to GET for 303 redirects). Or possibly because the spec really is that
bad. Upstream bug: haskell/HTTP#24

Since we absolutely don't want to download entire (large) files from
the web when checking that they exist with HEAD, I wrote my own redirect
follower, based closely on the one used by Network.Browser, but without
this misfeature.

Note that Network.Browser checks that the redirect url is a http url
and fails if not. I don't, because I want to not need to change this
code when it gets https support (related: I'm surprised to see it
doesn't support https yet..). The check does not seem security significant;
it doesn't support file:// urls for example. If a http url is redirected
to https, the Network.Browser will actually make a http connection again.
This could loop, but only up to 5 times.

Too bad this still has been unfixed for the last four years. I have the same use-case as joeyh and had a hard time figuring out why HTTP's result is so different from curl's one here. Maybe some programs rely on this redirection behaviour, so I propose adding a browser option to explicitly disable this GET redirection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment