RE: HTTP Endpoints and Resources

Hello David,  

>> Actually, though I'd love to take any credit, I didn't actually posit 
>> this. It's in the HTTP spec. The thing that responds with a 303 is a 
>> resource, in the sense in which that term is defined in RFC2616[1] 
>> (and which I've labelled http:resources for the purposes of this 
>> thread).
> 
> Where?  Section 1.4 says the *server* responds with the 303, 
> not the resource identified by the URI:
> 
> "The server responds with a status line, including the 
> message's protocol version and a success or error code . . . . "[2]

Ok, I guess I need to be more explicit. You're right in that the thing
that actually responds is the server. However, I read that part of [2] to
mean 'respond' in the most mechanical sense. The server doesn't itself
work out how to respond, apart from in the case of 404 and a few other
error codes to do with serious internal failures. 

In most cases, the server just packages up and sends the (bits, metadata)
it's been told to send. 

Notably, section 1.4 [2] also says:
 
"Most HTTP communication is initiated by a user agent and consists of a
request to be applied to a resource on some origin server." 

The way I read this is that an HTTP request is sent to a server. The
server applies it to an http:resource. The http:resource determines the
nature of the associated response. The server obediently packages up the
response and replies to the requester. 

Generation of 303 responses (or indeed any redirections) is no different
from generation of 200 responses in respect of this process. However,
errors like 404 are different. They arise either because the request can't
be applied to the http:resource or because something breaks during that
process. For these, the server can work out what to do all by itself.

Best wishes
Rhys

> 
> 
>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616.html
>> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1.4
>

Received on Tuesday, 2 October 2007 12:32:55 UTC