Re: Fragments in HTTP redirects

On 17.08.2010 19:10, Jonathan Rees wrote:
> 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.).

That's where we would be heading if we decide to recommend a specific 
outcome.

Also, for

    A#B and A ->  30x Location: C

we'd expect C#B (that's what most UAs implement).

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

I wouldn't have said "fanatics". But anyway, the UA implementers told 
us: "define what happens for HTML, we don't care about anything else" :-).

> This is a rathole. Simple solutions:
> - TimBL: no change to HTTP (disallow Location: C#D)

I don't think this works. It's implemented, people use it, and the HTTP 
community has treated this as a resolved problem since when it was 
raised (again: for over 10 years).

> - HTTPbis: pretend RDF doesn't exist (always discard first fragid even
> when meaningful)

The proposal is to discard the first fragid only when the redirect has 
another one (so the 2nd fragid, when present, takes priority).

> Complicated solutions:
> - make A->C#D mutually exclusive with A#B
> - only allow first fragid to be discarded when it would be meaningless

I'm not sure what these would mean in practice.

> - leave tertiary resource semantics up to media type registrations

That's a consistent point of view, but I'm afraid we couldn't agree on 
it in the WG so far.

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

The story goes like that:

- that fragids weren't in the grammar for Location was an oversight,

- browsers implement them,

- web resources use them, but

- the edge case of both original URIs and redirect having fragids was 
not considered.

Again: we're not inventing anything new; this has been around for a long 
time. Only the edge case of two fragids being around is undecided.

Best regards, Julian

Received on Tuesday, 17 August 2010 18:47:30 UTC