W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2004

Re: Can hash URI description lookups be made to scale?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 30 Jan 2004 14:18:06 +0200
Message-Id: <5BBC8E8C-531E-11D8-985B-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org
To: "ext Steve Harris" <S.W.Harris@ecs.soton.ac.uk>

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


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




Patrick Stickler
Nokia, Finland
Received on Friday, 30 January 2004 07:18:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:49 UTC