- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 30 Jan 2004 14:18:06 +0200
- To: "ext Steve Harris" <S.W.Harris@ecs.soton.ac.uk>
- Cc: www-rdf-interest@w3.org
On Jan 29, 2004, at 17:34, ext Steve Harris wrote: > > On Wed, Jan 28, 2004 at 07:02:38 +0000, Phil Dawes wrote: >> But with HTTP GET on hash URIs (if I understand correctly) the hash >> doesn't necessarily get to the server, so what's the best way to do >> this? I don't really want to serve a page with everyone on it >> (~gigabyte of data) >> Does this prohibit hash uris for this type of service? > > Youre right, but if the # is in a CGI argument it gets esacped (%23). > But GET http://example.com/2004/01/people#dawesp HTTP/1.0 is not the same request as GET http://example.com/2004/01/people%23dawesp HTTP/1.0 Those two distinct URIs may denote entirely different things. The problem is that the first request is at risk of becoming GET http://example.com/2004/01/people HTTP/1.0 because alot of software think (IMO rightly so) that the fragment identifier is relevant only within the context of interpretation of a representation returned by the base URI. So, when using URIrefs with frag ids, things can break. My advice would be to simply avoid the use of URIrefs for anything other than denoting logical components of digital resources. I.e. if you simply had GET http://example.com/2004/01/people/dawesp HTTP/1.0 then there'd be no worries... Cheers, Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Friday, 30 January 2004 07:18:57 UTC