Subject: RE: Fragments in "Location" field

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Sun, 15 Aug 1999 08:09:20 -0700

> >Regarding allowing fragments, I believe the same is the case for
> >Content-Location:
> >
> >       Content-Location = "Content-Location" ":"
> >                         ( absoluteURI | relativeURI )
> >
> >should be
> >
> >       Content-Location = "Content-Location" ":"
> >                         ( absoluteURI | relativeURI ) [ "#" 
> fragment ]
> 
> No, that would be incorrect.  The reference in 
> Content-Location must be
> to a resource, not a fragment of a resource representation.

The fragment (or view) is a function of the media type of the representation
chosen and hence does not have to be defined the same way across the set of
representations available for content negotiation of any particular
resource. For example, a fragment in HTML pointing to page 3 does not have
to be defined the same way for PS.

It is therefore functionally correct that Content-Location can contain a
fragment. The problem is of course that HTTP servers currently do not see
the fragment under normal circumstances because clients do not send it but
this is the same as for the Location header field. In fact, I consider this
a bug in HTTP :)

Henrik Frystyk Nielsen,
mailto:[email-masked]

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 15 Aug 1999 14:02:28 -0700

>to be defined the same way for PS.

A fragment is a fragment of a media type.  Content-Location refers to
the resource, not the representation of the resource as a media type.
A resource is not a media type, and therefore a fragment is not appropriate
for this field.

This is different from Location because Location is redirecting the
user agent to a different view, not identifying the resource included
in the message.

....Roy