- From: Justin Chapweske <justin@chapweske.com>
- Date: Wed, 23 Jun 2004 12:52:04 -0500
- To: Jamie Lokier <jamie@shareable.org>
- Cc: Henry Story <henry.story@bblfish.net>, ietf-http-wg@w3.org, Atom Syntax <atom-syntax@imc.org>, Alex Rousskov <rousskov@measurement-factory.com>
> That situation _definitely_ exists. Think of HTTP load balancers and > such. POSTs for a URI may be handled by different servers than GETs > for the same URI. > > I would think _most_ servers would route ERRs for a URI to the same > place that served that URI recently, _most_ of the time. > > That is enough to alert humans to a problem on their servers, which is > being detected by clients. > > > How could one deal with that situation, if that situation indeed exists? > > You let the server administrators figure it out. > This would be another example why an explicit error reporting URI in the response headers would be a better way to go. The system could dynamically include unique identifiers for the generating server and include that in the URI, and perhaps have all URIs for a cluster of servers point a single error reporting server. Adding new HTTP methods should only be done when there is no other sensible choice available. -- Justin Chapweske - Founder, Onion Networks http://onionnetworks.com/ 651-340-8787 Transfer large files 10x faster than FTP with Onion Networks' WAN Transport(tm). http://onionnetworks.com/products_wantransport.php
Received on Wednesday, 23 June 2004 13:54:55 UTC