Re: Fragments in HTTP redirects

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
http://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0256.html
and continues on www-tag here
http://lists.w3.org/Archives/Public/www-tag/2010Mar/0040.html

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.

Jonathan

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