Re: Review of new HTTPbis text for 303 See Other

On 16/7/09 10:01, Richard Cyganiak wrote:
> On 15 Jul 2009, at 18:22, Pat Hayes wrote:
>>>> A 303 response to a GET request indicates that the server does
>>>> not have a transferable representation of the requested resource
>>
>> Maybe I am misreading this. Consider an example, to help clarify. I
>> have an HTTP URI which, for reasons that need not detain us here but
>> which are set in stone, refers to a (non-information) resource, say
>> Richard Cyganiak the person. A GET with that URI resolves to an
>> endpoint which itself is (of course) a resource also, but not (of
>> course) the one that the URI denotes ("identifies"). Let us call this
>> resource R. This is the classical case that http-range-14 requires to
>> have a 303 emitted to the client by R, or at least by the http
>> endpoint associated with R. (I am never quite sure of exactly how the
>> 'resource' relates to the http endpoint, but let us try to ignore that
>> issue here: the main point is that R, whatever it is, is certainly not
>> Richard Cyganiak .) Now, in this scenario, what exactly is "the
>> requested resource" in the above wording?
>
> A good and helpful question.
>
> So let's do a GET on http://example.com:8080/people/richard_cyganiak.
>
> The way I see it, the requested resource is Richard Cyganiak. When I'm
> resolving the HTTP URI, a request is sent to a *server*, example.com, at
> port 8080, using the HTTP protocol, and the server responds with a
> certain status code. The HTTP interface/endpoint is the *server*, and
> not the individual resource. The resource -- the thing identified by the
> URI -- does not directly take part in the HTTP conversation. Its only
> relationship to the server is that a) the URI owner intends the URI to
> identify that resource, hence the server becomes responsible for
> answering requests to it, and b) the server holds (or not)
> representations of the resource.
>
> This is certainly not the only possible interpretation supported by the
> language in the relevant documents, and it requires some mental
> gymnastics, but this interpretation works well for me and answers the
> "how are you going to attach an HTTP endpoint to an imaginary thing"
> argument.

Hope this doesn't seem too much of a tangent, but I've been meaning to 
mention this for a while: a long time ago, Andy Powell made a nice demo 
of URN resolution using HTTP proxies, based on Netscape 4's behaviour of 
passing URNs along to proxies.

See http://www.dlib.org/dlib/june98/06powell.html

"However, Netscape Navigator version 4 does contain some support for 
URNs: if an HTTP proxy servier has been appropriately configured (see 
next section), it will pass URNs on to an HTTP proxy for resolution."

This reminds me - apparently it is OK to ask an HTTP server (or at least 
a proxy like http://en.wikipedia.org/wiki/Squid_(software) ) about 
things (er, resources) whose URIs don't begin http*. In the above case, 
Andy sent GETs for things with URNs...

I wonder how many of the URN namespaces registered in 
http://www.iana.org/assignments/urn-namespaces/ are used to name 
non-digital / non-serializable things?

cheers,

Dan

Received on Thursday, 16 July 2009 08:41:15 UTC