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

[Nicolas Petton <nicolas@petton.fr>]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Mon, Feb 1, 2016 at 11:42 PM, Nicolas Petton <nicolas@petton.fr> 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.

> 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.

I'm thinking about adding a variable, which when non-nil would follow
the redirection after a confirmation from the user for 301, 302 and 307
status code responses of all requests, regardless of the HTTP method.

This variable would default to nil, so that the current behavior is
unchanged by default.

Would that be ok with everybody?

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]