Re: Request for feedback on HTTP Location header syntax + semantics, Re: Issues 43 and 185, was: Issue 43 (combining fragments)

(bcc www-tag)

If you believe in the "identification" / "resource" / "representation"
theory then figuring this out if pretty straightforward.

Suppose redirects to, and
we want to know what resource is identified by
 In general resource x#y means y as locally defined in x. So is b as locally defined in  To find what's in, you
look at the resource  How a fragid is defined
locally in something depends on the media type registration, and the
only media type of which I'm aware that allows one to define locally a
fragid b to identify something that itself has representations with
the potential for fragid definition is application/rdf+xml (and the
other RDF media types). For text/html, for example, would identify an HTML element, and there's no
fragid namespace defined locally inside an HTML element in which #a
could be defined.

Usually, when a browser finds that a resource doesn't define the
desired fragid, it just shows you a representation of the resource. (I
vaguely remember some discussion about how the user should be alerted
when this happens, like a mild form of 404, but that's another story.)
To be consistent that is what should happen in this case. That is, it
would throw away the unresolvable #b and just show you (unless the representation of is RDF that defines d to be a resource that has a
locally defined b.)


On Thu, Mar 11, 2010 at 6:11 AM, Julian Reschke <> wrote:
> On 10.03.2010 19:12, Nathan Rixham wrote:
>> Hi All,
>>> 9.4.  Location
>>> ...
>>>     The field value consists of a single URI-reference.
>> If the Location header is only used to:
>>   1] identify a newly created resource
>>   2] redirect the recipient to a different location
>> doesn't this mean that:
>>   location-field-value = absolute-URI
>>                           / ( path-absolute [ "?" query ] )
>>                           / ( relative-part [ "?" query ] )
>> and fragments don't come in to the equation / should not be allowed?
> Fragments in redirect targets are nothing new. They have been around since
> the beginning, and they are supported by UAs. And they can be useful.
>> additionally how could a secondary resource (one identified by a
>> uri-reference containing a fragment) be accurately redirected-to when
>> secondary resources are not allowed in the request-target?
> I have no idea what this has to do with the request-target. Could you please
> elaborate?
> Best regards, Julian

Received on Thursday, 11 March 2010 12:32:17 UTC