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

On 11.03.2010 13:31, Jonathan Rees wrote:
> (bcc www-tag)
>
> If you believe in the "identification" / "resource" / "representation"
> theory then figuring this out if pretty straightforward.

I think that's a theory I believe in :-).

> 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

Interesting. How so? Pointer? Couldn't see that in 
<http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-fragID>.

> 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.)

The good thing is that the end result for text/html is the same: the 
fragment id from the redirect URL is taken into account, the original 
fragid being overridden.

So, considering that whatever has to happen here depends on the media 
type of the representation we get from the redirect target -- isn't this 
something the spec for text/html needs to spell out?

We currently have (in "-latest"):

"Note: This specification does not define precedence rules for the case 
where the original URI, as navigated to by the user agent, and the 
Location header field value both contain fragment identifiers."

How about expanding this to something like:

"Note: This specification does not define precedence rules for the case 
where the original URI, as navigated to be the user agent, and the 
Location header field value both contain fragment identifiers. In 
particular, the semantics of fragment identifiers depend on the 
representation's media type."

...and thus make it the HTML WG's problem (for text/html)? :-)

Best regards, Julian

Received on Thursday, 11 March 2010 17:55:45 UTC