- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 07 Oct 2009 19:27:22 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: "Yngve N. Pettersen" <yngve@opera.com>
Julian Reschke wrote: > Indeed. > > So I just put together a set of tests that use absolute URIs, paths (see > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>), and combined > them with frag ids. See <http://greenbytes.de/tech/tc2231/redirects.html>. > > The UAs I tested behaved consistently, except for the Opera issue noted > above. > > That being said, the UAs unfortunately are also consistent in ignoring > the fragment when it appears in a relative-ref, not a URI; this is > really bad as I wouldn't want to require different behaviors depending > on where the fragment identifier was in. > > Thus, *if* we address issue 43 by mandating that the fragment from the > Location header overrides a previous one, that should also apply for the > case of relative-refs, in which case all UAs would need to be fixed > (sigh!). > ... OK, let's summarize: 1) HTTPbis, in a very early draft, has fixed the ABNF of the Location header to allow fragment identifiers (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6>) 2) What it did not is define what a recipient should do when the referring URI contained a fragment identifier, and the Location header does as well. This is issue 43 (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43>) 3) In the meantime, people have asked for an even less strict ABNF, allowing relative URIs (Issue 185: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/185>) With respect to 2), we essentially have two choices: 2a) Point out that this is ambiguous, and leave it undefined. 2b) Document what many UAs do, as that happens to be sensible: in case both URIs contain a fragment id, the one from the Location header overrides the original URI, otherwise the original fragment identifier is appended to the new location. This is what was tested in the first four table entries at <http://greenbytes.de/tech/tc2231/redirects.html>; and it shows that UAs seem to be consistent here with the exception of Opera. But. For strange reasons, when seeing just an absolute path in the Location header, the UAs appear to ignore the fragment identifier. This really doesn't make any sense, because it appears that the implementations follow a completely different code path here. So for 3) the choices are: 3a) Leave the behavior undefined (possible even not allowing it in the ABNF) 3b) Document what makes sense (consistent with 2b), but point out that current implementations fail to do this 3c) Document what they do, even though it doesn't make any sense. I'm currently leaning to 2b/3b, but I could be convinced to do 2a/3a instead. However, I don't see how I could do 2b/3c. Feedback appreciated, Julian 3b)
Received on Wednesday, 7 October 2009 17:28:06 UTC