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 http://example.com/a redirects to http://example.com/c#d, and
we want to know what resource is identified by http://example.com/a#b.
 In general resource x#y means y as locally defined in x. So
http://example.com/a#b is b as locally defined in
http://example.com/a.  To find what's in http://example.com/a, you
look at the resource http://example.com/c#d.  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,
http://example.com/c#d 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
http://example.com/c#d. (unless the representation of
http://example.com/c is RDF that defines d to be a resource that has a
locally defined b.)

Jonathan

On Thu, Mar 11, 2010 at 6:11 AM, Julian Reschke <julian.reschke@gmx.de> 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:26 UTC