- From: Dan Brickley <danbri@danbri.org>
- Date: Thu, 16 Jul 2009 10:40:32 +0200
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Pat Hayes <phayes@ihmc.us>, "www-tag@w3.org WG" <www-tag@w3.org>
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