[VM] frag ids, 303, and browsers (was RE: httpRange-14: Use Case for RDF [302 versus 303 redirects])

Hi David,

> David Wood and I tested a few browsers (IE6, Firefox, Safari, 
> Amaya and
> I don't recall what else) to see what they do with the fragment
> identifier when a URI does 303 redirect, and the result was that some
> browsers apply the original fragment identifier to the 
> secondary URI and
> some discard it.  For example, if the original URI is
> http://original.example.org#red but http://original.example.org
> 303-redirects to http://secondary.example.org then some 
> browsers display
> the results as http://secondardy.example.org#red  and some display the
> results as http://secondardy.example.org.  

Actually, some browsers (e.g. IE6) *do* try to apply the frag id to the response from the secondary URI, and therefore *do* scan to the corresponding part of the document if the anchor exists, but *don't* actually display the frag id in the URL bar. Did you check this?

E.g. try putting the following URI into IE6:

http://www.w3.org/2004/02/skos/core/spec/#symbol 

Mozilla/Firefox are different from IE6 in that they retain the frag id in the URL bar after redirects.

Cheers,

Al.



> 


> Given this evidence of varying behavior in a parallel case (302
> redirects instead of 303 redirects) it seems unwise to make 
> assumptions
> about what the behavior should be for 303 redirects in the absence of
> clear guidance in the HTTP specification.
> 
> CONCLUSIONS
> It is unclear what a 302 redirect should mean, in trying to determine
> what a URI identifies.  Unless this is clearified by the TAG, 
> I think it
> would be best to stick with URI minting and redirecting 
> mechanisms whose
> meaning is clearer, specifically:
> 
> 	- hash URIs that are not redirected (suitable for URIs that 
> 	  identify information resources, and for URIs that identify
> other
> 	  things if the media type will always be RDF/XML or similar);
> and
> 
> 	- slash URIs that are redirected using HTTP 303 status code
> 	  (suitable for identifying anything).
>   
> For this reason, I think it would make sense to change purl.org to use
> 303 redirects instead of 302, or perhaps permit the response 
> code to be
> a configuration option for the URI sub-space owner.
> 
> Finally, since it is not clear what the user agent treatment 
> of fragment
> identifiers should be in the presence of 303 redirects, it may be wise
> to avoid them when minting URIs that intend to use 303 redirects.  [An
> HTTP expert should please correct me if the HTTP specification is
> already clear on this!]
> 
> References
> 1. HTTP status codes:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> 2. TAG's httpRange-14 decision:
> http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
> 3. DanBri's TAG question about 302 versus 303:
> http://lists.w3.org/Archives/Public/www-tag/2005Jul/0012.html
> 4. RFC 3986 (URI syntax):
> http://www.ietf.org/rfc/rfc3986.txt
> 
> 
> 
> 
>

Received on Tuesday, 17 January 2006 16:12:54 UTC