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

[Yuri Khan]

On Mon, Feb 1, 2016 at 11:42 PM, Nicolas Petton <address@hidden> wrote:

> What should we do then?  The current implementation seems to just
> ignores the redirection, I would at least ask the user for a
> confirmation.

That’s the million dollar question, of course :)

Well-behaved contemporary sites should probably not respond with 301
and 302 to POST requests, preferring 303 for “I have processed your
request, now please navigate to this new page” and 307 for “I have not
processed your request but the handler on that other URI might”.

Older sites probably expect 301s and 302s to be handled by the client
in the fashion that is correct for 303. Sites that use 301 and 302
redirects as intended expect them to be handled like 307.

If I were designing an HTTP client library now, I would handle 301 and
302 the same way as 307 by default: no confirmation, no method change,
send the same request data. But I would provide an escape hatch — a
single flag that, when explicitly specified, forbids following
redirects and just returns the 30x codes to the application which
should then decide what to do. I would cite RFC 7231 to everybody who
complained about my choice of defaults ;)

cURL does not follow redirects by default. When directed to with the
-L/--location switch, it defaults to changing the method to GET for
301, 302 and 303 but keeping the original method for 307. It has
further switches --post301, --post302 and the bizarre --post303 to
keep POST method for these respective redirects. Its manual says the
default behavior is non-compliant.

Wget, on the other hand, keeps the original method on 301, 302 and
307, and the manual says it is with accordance to RFC 2616.