W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: Protocols/APIs and redirects

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 8 Dec 2011 11:59:16 +1100
Cc: "Julian Reschke" <julian.reschke@gmx.de>, "HTTP WG" <ietf-http-wg@w3.org>
Message-Id: <7BD18309-2771-47A2-ADB1-3319FB3C68C7@mnot.net>
To: Anne van Kesteren <annevk@opera.com>

On 08/12/2011, at 2:22 AM, Anne van Kesteren wrote:

> On Wed, 07 Dec 2011 12:57:48 +0100, Julian Reschke <julian.reschke@gmx.de> wrote:
>> My understanding is that it depends, and needs to decided on a per-header basis. We can try classifications that make it easier to decide, and we may even be able to recommend a default, but this will break when a new header needs the non-default behavior.
> I don't think that will work for us. It needs to be the same irrespective of the header. Or some kind of fixed unchanging list for which things is different.

Unfortunately, that's how it works. 

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. 

>> The base issue is splitting the responsibilities between two layers, and have the lower layer (XHR) trying to decide things that the upper layer (the script) should know.
>> I'm not sure what this has to do with "HTML Fetch", as the problem is specific to XHR. I recommend to fix the base issue first, which is that clients can't ask XHR not to follow redirects.
> XMLHttpRequest uses HTML fetch. Server-sent events does too, and a number of other things affected do so as well. You indeed keep bringing up that we should add a feature to XMLHttpRequest and that it will resolve the problem. But adding a feature does not resolve the problem. We will still have the problem for when such a feature is not used. So lets address that. Adding a feature for redirects is completely orthogonal as I explained several times now. I am getting somewhat tired of having to repeat myself.

OK. We seem to be repeating ourselves as well; the solution you're looking for isn't in this direction, at least as far as we can see.

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.


Mark Nottingham
Received on Thursday, 8 December 2011 00:59:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:54 UTC