- From: Justin Chapweske <justin@chapweske.com>
- Date: Thu, 16 Jun 2005 08:42:28 -0500
- To: "S. Mike Dierken" <mdierken@hotmail.com>
- Cc: "Kumar C." <kumarc@jataayusoft.com>, Mark Nottingham <mnot@mnot.net>, www-talk@w3.org
I feel that HTTP is more of a protocol for resolving URIs than a protocol for talking to a server. With HTTP's explicit support for proxying, including transcoding proxies, I think it would be incorrect to assume that an HTTP conversation is necessarily talking to a server. The fact that there is a host name in an HTTP URI is simply an indication of authority and a hint as to where that content could be retrieved. Intermediaries are basically allowed to do whatever the want to resolve that URI. Even on the backend, load balancers and reverse proxy configurations are very common, so even though you've connected to an IP address and are participating with an HTTP conversation with that machine, it could be that it is using a number of different backing servers to handle various parts of the URI space. So if my search box is overloaded, I might get 503s on the /search name space, while my static content serving is working just fine. Just my opinion. -Justin On Wed, 2005-06-15 at 21:07 -0700, S. Mike Dierken wrote: > I've always interpreted the HTTP as talking to a server about a resource - > the response codes come from 'the server', so 'server unavailable' means the > entire server. Why wouldn't a 40x response code be sufficient for the > availability of individual resources? > A system of "/servlet/search?query=foo" could be separated from > "/servlet/login?user=foo" via a resource specific 40x or 307 (temporary > redirect) response. -- Justin Chapweske <justin@chapweske.com>
Received on Thursday, 16 June 2005 13:46:09 UTC