W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2004

Re: Proposal for an HTTP ERR method

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>
Message-Id: <1088013124.27193.228.camel@bog>

> 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
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:37 UTC