- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 07 Dec 2011 12:57:48 +0100
- To: Anne van Kesteren <annevk@opera.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP WG <ietf-http-wg@w3.org>
On 2011-12-07 10:53, Anne van Kesteren wrote: > On Wed, 07 Dec 2011 02:42:50 +0100, Mark Nottingham <mnot@mnot.net> wrote: >> Sorry, Anne; I couldn't find it either, so I've just created >> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/328>. >> >> The discussion wound up here: >> <http://www.w3.org/mid/op.vygkyybt64w2qv@annevk-macbookpro.local>. As >> others have mentioned, I don't think there's much we can say about >> this, other than mentioning it as something that people who define new >> headers should consider. > > Is that another way of saying we should define the behavior in the HTML > fetch algorithm? 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. 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. Best regards, Julian
Received on Wednesday, 7 December 2011 11:58:35 UTC