W3C home > Mailing lists > Public > www-tag@w3.org > August 2007

RE: ISSUE-57: The use of HTTP Redirection

From: Rhys Lewis <rhys@volantis.com>
Date: Wed, 29 Aug 2007 06:03:04 -0700 (PDT)
To: "'Richard Cyganiak'" <richard@cyganiak.de>, "'Booth, David \(HP Software - Boston\)'" <dbooth@hp.com>
Cc: "'Tim Berners-Lee'" <timbl@w3.org>, "'Ed Davies'" <edavies@nildram.co.uk>, "'Technical Architecture Group WG'" <www-tag@w3.org>
Message-ID: <009e01c7ea3d$491b9ec0$0202fea9@volantisuk>

Hello Richard, 

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Richard Cyganiak
> Sent: 29 August 2007 13:15
> To: Booth, David (HP Software - Boston)
> Cc: Tim Berners-Lee; Ed Davies; Technical Architecture Group WG
> Subject: Re: ISSUE-57: The use of HTTP Redirection
> 
> 
> 
> On 28 Aug 2007, at 22:19, Booth, David (HP Software - Boston) wrote:
> 
> >
> >> From:  Tim Berners-Lee
> >> [ . . . ]
> >>
> >> Often, people use the term "non-information resource" to 
> mean "some 
> >> resource, not necessarily an information resource".
> >
> > Good Lord, I hope not!  Please chastise anyone who is doing so!  We 
> > have enough chaos without changing the English meaning of "non-".
> 
> An example perpetrated by, uh, me:
> 
> [looking at an HTTP response] "This is a 303 redirect, which 
> tells the client that the requested resource is a 
> non-information resource, and its associated description can 
> be found at the URI given in the
> Location: response header." [1]
> 
> This is incorrect, because 303 doesn't really tell us 
> *anything* about the nature of the resource, except that 
> associated information might be found somewhere else.
> 
> My incorrect statement was motivated by the question why hash URIs or
> 303 URIs or 200 URIs should be used in a particular case. 
> Usually, the answer goes like this: If you have an IR, you 
> can use 200. If you have a non-IR, you must use 303 or a hash 
> URI. Unfortunately, that's not the whole story. There is this 
> grey area where you *may* or even
> *must* identify normal IRs using hash URIs or 303 URIs. That 
> grey area is a mess.
> 
> There's a lot of discussion currently about the distinction 
> between IRs and non-IRs. Is it about "essential 
> characteristics conveyable in a message", about "can we 
> attach an HTTP endpoint to it", about "document-ness"?
> 
> To me, this all misses the point. Even if we can nail down 
> objective criteria to distinguish these buggers, this will 
> *still* not tell us if we have to serve them up using 303/hash or 200.
> 
> So, can anyone shed light on this? If I mint a URI, what's 
> the criterion for setting up 200 vs. 303/hash? Keep in mind Tim's
> example: CERN could set up a 303 redirect from some early-day 
> WWW URIs of historic interest, to a "museum page" hosted at 
> today's W3C site.

Let me try and tease this apart to see if I understand why you think this
is a problem.

In Tim's example, the CERN 303 redirect simply says there is no
representation for the early day WWW URI. That URI identifies a
non-information resource. There is no representation available. The nature
of the URI that CERN gives back in the 303 is completely indeterminate. It
could be an information resource, or a non-information resource, or could
lead to another redirect, for example. (And of course it could lead to a
plethora of other response codes indicating various form of error that
I'll ignore here).

Assuming the URIs are set up correctly, and the URI provided by CERN in
the 303 does indeed identify an information resource, a representation can
be retrieved and everything has worked out as intended.

Surely the criterion for minting URIs is straightforward. If the URI is
for an information resource (provides representations) you return a
suitable representation, if you have one, and a 200 response coed (let's
ignore content negotiation for the purposes of this discussion). If,
however, the URI is for a non-information resource, you have two options.
You can return a 303 and a helpful URI. You're not allowed to return a
representation according to HTTP. If you prefer, you return a
representation of the racine, which is not a representation of the hash
URI. 

You cover all this in your paper. The only statement that appears to go
beyond what has been generally accepted to date is to say that the URI in
the 303 necessarily provides some kind of description of the
non-information resource. At the moment, the httpRange-14 draft finding
[2] says that authors SHOULD do this when using the 303 mechanism with
non-information resources. Some people would like this statement to be
stronger. We think that we can encourage people to use 303 this way for
the particular purpose of associating additional information with
non-information resources. We have to be careful about revising the
meaning of 303 to mean only this, however. It's been in the wild for a
long time.

Apologies if I'm missing something deeper. 

By the way, the range14 draft has taken a bit of a public beating over the
last week or so. There will be some changes. I sense that there is quite a
bit of interest in stronger statements about certain redirections,
including 303, though.

Best wishes
Rhys 



[2]
http://www.w3.org/2001/tag/doc/httpRange-14/2007-08-31/HttpRange-14.html



> 
> Richard
> 
> [1] http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/ 
> LinkedDataTutorial/#ExampleHTTP
> 
> 
> 
> >
> >
> >
> > David Booth, Ph.D.
> > HP Software
> > +1 617 629 8881 office  |  dbooth@hp.com
> > http://www.hp.com/go/software
> >
> > Opinions expressed herein are those of the author and do 
> not represent
> > the official views of HP unless explicitly stated otherwise.
> >
> >
> >
> 
> 
> 
Received on Wednesday, 29 August 2007 13:03:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:47 GMT