W3C home > Mailing lists > Public > www-tag@w3.org > August 2010

Re: Fragments in HTTP redirects

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 17 Aug 2010 13:10:17 -0400
Message-ID: <AANLkTi=9zHpgK68wgcL6AqHS7RUx8YcssVGyj+xXAuOu@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: www-tag@w3.org, Tim Berners-Lee <timbl@w3.org>
Yes, thanks Yves, especially for draft-bos-http-redirect-00 .

I'm about to repeat myself. I see that we discussed this recently,
around March 11... thread starts on http-wg here
and continues on www-tag here

It looks like the consensus on http-wg is that the second fragid
overrides the first, i.e. if we want A#B and A -> 30x Location: C#D,
then A#B is to be interpreted like C#D (as is A#W, A#J, etc.).

There is a web architecture view of #, which is that A#B designates
secondary resource B as defined in one of the 'representations' of
<A>. Maybe we can agree that if A redirects to C#D and C#D designates
(per C's 'representation's' media type) an HTML element or some other
inherently fragment-like thing, then A#B should be treated like C#D,
discarding the 'B': A#B ~= A.

But if C#D designates a secondary resource that itself has
'representations' and tertiary resources, then it's sensible for A#B
to be treated like B as defined in C#D, and not like C#D itself. If
you buy this idea, you wouldn't want the HTTP spec to rule out
interpreting A#B that way - that's not its jurisdiction. In fact I
think 3986 already points in this direction.

In practice, nontrivial tertiary resources can only arise via RDF, and
don't occur in the wild AFAIK. Weird non-deployed RDF is of interest
to only a handful of fanatics.

This is a rathole. Simple solutions:
- TimBL: no change to HTTP (disallow Location: C#D)
- HTTPbis: pretend RDF doesn't exist (always discard first fragid even
when meaningful)

Complicated solutions:
- make A->C#D mutually exclusive with A#B
- only allow first fragid to be discarded when it would be meaningless
- leave tertiary resource semantics up to media type registrations

I was hoping you would turn up use cases. The email from Roy that
Julian cites doesn't provide any rationale, nor have I found much to
work with anywhere else. It's hard to figure out why this matters at
all - either the simple Location: C#D case or the double-fragid case.


On Tue, Aug 17, 2010 at 5:37 AM, Yves Lafon <ylafon@w3.org> wrote:
> Hi,
> During the last teleconference, we discussed fragment handling in redirect
> now that fragments are allowed in redirects (in httpbis).
> Here is the history of allowing them:
> It is httpbis issue #6 [1], so part of the RFC2616 errata [2].
> It relates to the following thread [3] where the discussion about fragment
> combination started [4], and also about the difference between CL and
> Location [5], and the CGI definition at [6], and draft-bot-http-redirect [7]
> So the discussion started in 1999, with some questions left open, and
> included in the errata.
> Cheers,
> [1] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/6
> [2] http://purl.org/NET/http-errata
> [3]
> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/thread.html#103
> [4]
> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0106.html
> [5]
> http://lists.w3.org/Archives/Public/ietf-http-wg-old/1999MayAug/0115.html
> [6] http://ken.coar.org/cgi/draft-coar-cgi-v11-03-clean.html#
> [7] http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>        ~~Yves
Received on Tuesday, 17 August 2010 17:10:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:35 UTC