Re: Protocols/APIs and redirects

On 09/12/2011, at 4:27 AM, Anne van Kesteren wrote:

> On Thu, 08 Dec 2011 01:59:16 +0100, Mark Nottingham <mnot@mnot.net> wrote:
>> Consider -- right now, for every request, implementations decide what headers to send, based upon a number of factors. There are a very few that are required by HTTP (e.g., Host), many that are optional, depending upon the implementation (e.g., Connection, Accept-*, User-Agent), some that depend upon the situation (e.g., Referer), the internal state of the client (e.g., Authorization, If-Modified-Since, If-None-Match), or the request itself (e.g., If-Match, Content-Type).
>> 
>> All of these considerations apply to redirect requests as well.
> 
> That makes a lot of sense to me and for headers that are integral part of the protocol I agree they might differ per request.
> 
> This question in particular is for higher level API that implements the protocol and automatically follows redirects, but does not implement the protocol's extensions (either standardized, like WebDAV, or proprietary, such as X-User-Screen-Size). The library should of course set the basic headers as appropriate depending on what the request URL ends up being. But it seems to me than other than that it can only repeat the request to the new URL.

Or omit it.

Consider Cookie, for example -- which isn't part of HTTP, but is an extension (albeit widely-used). It effectively implements its own protocol, and it would be surprising (possibly disastrous) if you blindly copied a cookie from one domain to another upon a redirect.

That doesn't happen, of course, because browsers implement and understand cookies; likewise, I'd expect that any other code in a browser handling a specific header-based protocol would deal with redirects as a consequence of how it's implemented.

The tricky bit is when people want to implement such protocols using just XHR, rather than have the browser handle them. 


>> If you'd like to make a concrete proposal, we'd be more than happy to discuss it, but keep in mind that to be in the HTTP spec, it needs to be applicable to all uses of HTTP, not just a subset of them.
> 
> It seems the path of least resistance here is that XMLHttpRequest defines that "author request headers" (headers authors can set) are included in the request to the new URL. That HTML defines that Last-Event-ID for EventSource is included when there's a redirect. That Ping-To and Ping-From are included.

That seems reasonable. 

> Since all these go through HTML fetch it may turn out that for the purposes of HTML fetch additional headers set should always be included in redirects.


OK. I'm going to close the ticket with no change, unless I hear otherwise from you.

Note that we've already incorporated some text here:

>    Authors of specifications defining new header fields are advised to
>    consider documenting:
[...]
>    o  Whether the header field should be preserved across redirects.


<http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-3.1>

Cheers,





--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 9 December 2011 05:42:07 UTC