Re: Protocols/APIs and redirects

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.


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

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.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 8 December 2011 17:28:42 UTC