Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
joeyh opened this issue Feb 11, 2012 · 2 comments
Open

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

joeyh opened this issue Feb 11, 2012 · 2 comments

Comments

@joeyh
Copy link

joeyh commented Feb 11, 2012

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.
@hsenag
Copy link
Member

hsenag commented May 10, 2012

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 pushed a commit to kaostao/git-annex that referenced this issue Mar 28, 2014
@joeyh
work around Network.Browser bug that converts a HEAD to a GET when fo…
ecfcb41 
…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.
@pavonia
Copy link

pavonia commented Feb 21, 2016

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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@joeyh @hsenag @pavonia