- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 17 Aug 2010 20:46:49 +0200
- To: Jonathan Rees <jar@creativecommons.org>
- CC: Yves Lafon <ylafon@w3.org>, www-tag@w3.org, Tim Berners-Lee <timbl@w3.org>
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