3xx redirects - request formation

[mnot]

see whatwg/fetch#609

[reschke]

Well, the issue here is that the HTTP specs really say almost nothing about how the redirect happens (what header fields to include, for instance). If it did, then yes, this should be covered as well.

[mnot]

Yes, that's the focus.

Perhaps a starting point would be to talk about how the HTTP-defined headers and other protocol artefacts are copied / not copied / modified when following a redirect -- even if for some we have to say "depends upon the application", so applications know they have to cover this.

[mnot]

Discussed in Montreal; support for trying.

[royfielding]

Seems reasonable, but where? At the top of 3xx section?

[mcmanus]

in bkk: agreed to add more explanatory language; discussion contained references to the case of relative uris after redirects

[mnot]

For reference, the relevant part of fetch.

Waiting for #165 to sort out hop-by-hop headers.

[mnot]

rough proposal:

When automatically following a redirected request, a User Agent SHOULD resend the original request message with the following modifications:

1. Replace the target URI with the URI carried by the redirection responses' Location header field
2. Remove connection-specific header fields [ref] (if any)
3. Add new connection-specific header fields as appropriate to the connection the new request occurs upon
4. Remove origin-specific header fields (if any), including (but not limited to) WWW-Authenticate, Cookie, 'Host'
5. Add new origin-specific header fields as appropriate to the origin the new request is being sent to
6. Remove validating header fields that were added by the implementation's cache (If-None-Match, If-Modified-Since) and replace them based upon the updated target URI, as appropriate
7. Remove resource-specific header fields (if any), including (but not limited to) Referer, Origin
8. Add new resource-specific header fields as appropriate to the resource the new request is being sent to
9. Change the request method according to the redirecting status code's semantics, if applicable
10. If the request method has been changed, remove content-specific header fields (if any), including (but not limited to) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, ETag, Last-Modified

[annevk]

Note whatwg/fetch#944 for some drawbacks.

[reschke]

0 -- Need to decide when to automatically redirect for a new 3xx. Triggered by presence of "location"?
1 -- And potentially resolved against the original URI.
10 -- The only method to ever change to is GET, right? (for 301, 302, 303)

[mnot]

0 - yes, but ultimately the decision is in the client's hands; i.e., we can't make any requirements here.

1 - yes

10 -- yes

[mnot]

@annevk I think we can address that with some general language to the effect that the overriding principle is: things automatically added by the implementation need to be removed and re-added as appropriate, whereas things added by the user (caller, developer, etc.) need to be preserved -- with potential exceptions for security purposes, such as Authorization.

Will start a PR.