- From: Williams, Stuart \(HP Labs, Bristol\) <skw@hp.com>
- Date: Mon, 27 Nov 2006 17:43:19 -0000
- To: "Alistair Miles" <a.j.miles@rl.ac.uk>
- Cc: <public-swd-wg@w3.org>
Alistair, I'd had a look at the "Best Practice Recipes for Publishing RDF Vocabularies" [1] and was troubled by one small thing in receipe #4. In the third diagram [2] does a redirect with a Location header that includes a fragment in the redirection. It's not at all clear to me that the http specs allows the inclusion of a fragment id in a redirection. I know that the redirections on http://purl.org/dc/elements/1.1/title etc. do something similar (curiously, the last time I looked there was no 'target' in the resulting representation corresponding the location URI http://dublincore.org/2006/08/28/dces.rdf#title). On Location headers in RFC2616 (p135) states: "For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = "Location" ":" absoluteURI" where absoluteURI is referenced from RFC2396 (now obsoleted by RFC3986) and does *not* carry an optional fragment. Looked at differently from a non-spec-legalistic pov, allowing a frag id on a redirection seems puzzling. Imagine that the original reference has a fragID. You keep that in your back pocket (to be applied to a subsequent retrieved representation), dereference the URI (which strips the frag ID from the http request line) and get a redirection with a fragID... now you have two... this could repeat arbitrally many times before you end up with a representation and a pile of frag ids in your hands. Which one would you then apply? First, last, random choice, none? It strikes me that it was never intended for location headers to carry fragment. BTW I have *not*looked around for errata, FAQs etc. that address this question. BR Stuart -- [1] http://www.w3.org/TR/swbp-vocab-pub/ [2] http://www.w3.org/TR/2006/WD-swbp-vocab-pub-20060314/img/deref-cp-uri-ht ml.png
Received on Monday, 27 November 2006 17:44:02 UTC