Re: 307 status code handling in url-http-parse-headers

[Yuri Khan <yuri.v.khan@gmail.com>]

On Mon, Feb 1, 2016 at 8:30 PM, Nicolas Petton <nicolas@petton.fr> wrote:

> I see that `url-http-parse-headers' won't redirect a 307 response for a
> POST request.
>
> There's a comment about 301/302 status codes, which says that for other
> requests than HEAD and GET, the user agent must not automatically
> redirect, which seems to follow the RFC.
>
> However, should we ask the user confirmation for the redirection and do
> the redirect depending on the user's choice?

The sad tale of HTTP redirections :(

HTTP/1.0 (RFC 1945) defined 301 and 302 requiring confirmation on
redirecting methods other than HEAD and GET. The intent was that it
was unknown whether the original handler performed the requested
operation before responding with a redirect. The intent was also that
in case of user confirmation the client would follow the redirect with
the original method.

Both browser implementors and web developers misunderstood the spec
and used 301 and 302 redirects to mean “I have performed the operation
you requested; follow the redirect with a GET to see results and/or
further instructions”.

RFC 2068 recognized the above use case and introduced the 303 code to
mean exactly that. It clarified that changing POST to GET on a 301 or
302 is an error. Still requires confirmation before redirecting
non-idempotent methods with 301 or 302, but not for 303.

HTTP/1.1 (RFC 2616) introduced the 307 code with pretty much the same
wording as RFC 2068 for 302, possibly in expectation that this time
developers will get it right. It required a confirmation on the 307,
as well as 301 and 302.

The current version of HTTP/1.1 (RFC 7231) no longer requires
confirmation on 301, 302 or 307. It documents that some clients MAY
(but actually should not) change POST to GET on 301 and 302. It
clarifies that clients MUST NOT change the method on a 307.