Frag Ids in location headers

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