W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: Proxies and gethostbyname

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 28 Apr 1998 11:06:49 -0700 (PDT)
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: Jim Gettys <jg@pa.dec.com>, http-wg@cuckoo.hpl.hp.com, http-wg@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980428110128.21305D-100000@shell1.aimnet.com>


On Tue, 28 Apr 1998, Roy T. Fielding wrote:

> >My current opinion is that returning 504 Gateway Timeout is correct, but 
> >that clarification to the spec is in order.  But other options include 
> >introducting other error codes, or less likely, some other existing error 
> >code.
> 
> Ditto.  504 is sufficient, but we might do better.  The general question
> in deciding on a response code is whether the "here's what you should do
> next" semantics are equivalent to an existing response code, and whether
> the "next" thing can be accomplished automatically or only by some real
> person looking at the error response message.
> 
> In my opinion, a failure to resolve a DNS name is equivalent to a
> failure to connect to the resolved IP address -- the reason being that
> both are components of the resource resolution process.  A more general
> status code would therefore be a new "5aa Unable to Resolve URI", with
> the explanation of why being included in the response message.  This is
> different from 404 Not Found since it does not imply an authoritative
> response.  Likewise, we would gain nothing from further differentiation
> of all possible resolution failure causes into separate error codes,
> since there is nothing whatsoever that the client can do "next" aside
> from display the cause or try a different proxy (i.e., all of those
> failures are equivalent).

I disagree ... there is a large difference between not being able to
resolve a name and not being able to connect to an IP address.
The first order problem resolution for the DNS failure will in may cases
be the user checking the URL they typed for correctness. Failure to
connect to the resolved IP address is also different from connection
refused in terms of recovery strategy.  All of those distinctions are
useful for further problem determination by human analysists. And even
when the automated portion of a client can't distinguish, the ability to
collect failure statistics with distinct failure reasons may be helpful.

Dave Morris
Received on Tuesday, 28 April 1998 11:16:26 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:15 EDT