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

Proxies and gethostbyname

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 27 Apr 1998 11:06:40 -0700
Message-Id: <9804271806.AA25211@pachyderm.pa.dec.com>
To: http-wg@cuckoo.hpl.hp.com
Clarification is needed on what error is to be returned if a Proxy
times out looking up a hostname.  The spec is silent on what is a very
common failure.

My current opinion is that returning 504 Gateway Timout 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.

Other opinions?
				- Jim Gettys

> View: Browse HTML    Browse Raw Text
> From: jg@pa.dec.com (Jim Gettys)
> Date: Mon, 27 Apr 1998 07:27:49 -0700
> To: Ari Luotonen <luotonen@netscape.com>
> Cc: erik@netscape.com, montulli@netscape.com,
> phadnis@netscape.com
> Cc: fielding@ics.uci.edu, mogul@pa.dec.com,
> frystyk@w3.org,
>         masinter@parc.xerox.com
> Subject: Re: proxies and gethostbyname [RESEND]
> 
> Yup.  I'm surprised the spec isn't clear on this point as well, given
> how common this problem is....
> 
> We need to clarify this for draft standard, in my opinion.  This is at
> least an editorial problem that must get fixed.
> 
> My initial reaction is also that it should be a 500 class error.
> 
> The closest code currently defined is 504 Gateway Timeout.  Even there,
> clarification is really needed.
> 
> Do you have any problems with me taking the discussion to the
> working group mailing list for resolution?
>                                 - Jim
> 
> 
> > Sender: luotonen@netscape.com (Ari
> > Luotonen)
> > From: Ari Luotonen <luotonen@netscape.com>
> > Date: Fri, 24 Apr 1998 20:33:00 -0700
> > To: erik@netscape.com
> > Cc: montulli@netscape.com, phadnis@netscape.com,
> > jg@pa.dec.com
> > Subject: Re: proxies and gethostbyname [RESEND]
> >
> > [Resending with JG's e-mail corrected.]
> >
> > Eric,
> >
> > I'm Cc'ing Jim Gettys of W3C re: "should there be an HTTP status
> > code for proxy failure to DNS resolve".
> >
> > Jim,
> >
> > Please see below. --Thanks!!
> >
> > -- Cheers, Ari --
> >
> > Erik van der Poel wrote:
> > > Ari Luotonen wrote:
> > >> Erik van der Poel wrote:
> > >>>
> > >>> Hi Lou and Ari,
> > >>>
> > >>> If Navigator is using an HTTP proxy, and it asks the proxy to
> > >>> resolve a URL that contains a non-existent hostname (i.e.
> > >>> gethostbyname() fails in the proxy), what is the proxy
> > >>> supposed to return? Is it supposed to return 404, or 400, or
> > >>> what?
> > >>
> > >> Our UNIX proxy returns 500.  It shouldn't be 404 because I
> > >> think HTTP status codes refer to objects within servers, not
> > >> the existence or non-existence of servers themselves.  Since
> > >> the proxy is not the originator of the data, it cannot
> > >> definitively determine the existence or non-existence of a
> > >> server (or an object within a server) -- in a case where it
> > >> fails to connect to one (regardless of whether the reason is
> > >> DNS, server down, or midstream proxy down).  Only an origin
> > >> server can say something like "404 Not found" or "410 Gone".
> > >>
> > >> It shouldn't be 400 because the request format itself was ok.
> > >> I further think that it shouldn't be any 4xx class status code
> > >> (client's request bad), since the problem may be a temporary
> > >> DNS problem, or a problem on the proxy itself.  I would
> > >> therefore continue to vote that 500 (or some other 5xx class
> > >> status code) is the correct code for this case.
> > >
> > > This all sounds very reasonable. I guess I'm just a little
> > > surprised that the HTTP spec itself does not specify the error
> > > number to use in this case. We seem to be doing the right
> > > thing: i.e. we are passing the absolute URL to the proxy, and
> > > asking the proxy to retrieve that object. Is the omission of
> > > the error number for this case a "bug" in the HTTP spec?

attached mail follows:


Yup.  I'm surprised the spec isn't clear on this point as well, given
how common this problem is....

We need to clarify this for draft standard, in my opinion.  This is at
least an editorial problem that must get fixed.

My initial reaction is also that it should be a 500 class error.

The closest code currently defined is 504 Gateway Timeout.  Even there,
clarification is really needed.

Do you have any problems with me taking the discussion to the
working group mailing list for resolution?
				- Jim


> View: Browse HTML    Browse Raw Text
> Sender: luotonen@netscape.com (Ari
> Luotonen)
> From: Ari Luotonen <luotonen@netscape.com>
> Date: Fri, 24 Apr 1998 20:33:00 -0700
> To: erik@netscape.com
> Cc: montulli@netscape.com, phadnis@netscape.com,
> jg@pa.dec.com
> Subject: Re: proxies and gethostbyname [RESEND]
> 
> [Resending with JG's e-mail corrected.]
> 
> Eric,
> 
> I'm Cc'ing Jim Gettys of W3C re: "should there be an HTTP status
> code for proxy failure to DNS resolve".
> 
> Jim,
> 
> Please see below. --Thanks!!
> 
> -- Cheers, Ari --
> 
> Erik van der Poel wrote:
> > Ari Luotonen wrote:
> >> Erik van der Poel wrote:
> >>>
> >>> Hi Lou and Ari,
> >>>
> >>> If Navigator is using an HTTP proxy, and it asks the proxy to
> >>> resolve a URL that contains a non-existent hostname (i.e.
> >>> gethostbyname() fails in the proxy), what is the proxy
> >>> supposed to return? Is it supposed to return 404, or 400, or
> >>> what?
> >>
> >> Our UNIX proxy returns 500.  It shouldn't be 404 because I
> >> think HTTP status codes refer to objects within servers, not
> >> the existence or non-existence of servers themselves.  Since
> >> the proxy is not the originator of the data, it cannot
> >> definitively determine the existence or non-existence of a
> >> server (or an object within a server) -- in a case where it
> >> fails to connect to one (regardless of whether the reason is
> >> DNS, server down, or midstream proxy down).  Only an origin
> >> server can say something like "404 Not found" or "410 Gone".
> >>
> >> It shouldn't be 400 because the request format itself was ok.
> >> I further think that it shouldn't be any 4xx class status code
> >> (client's request bad), since the problem may be a temporary
> >> DNS problem, or a problem on the proxy itself.  I would
> >> therefore continue to vote that 500 (or some other 5xx class
> >> status code) is the correct code for this case.
> >
> > This all sounds very reasonable. I guess I'm just a little
> > surprised that the HTTP spec itself does not specify the error
> > number to use in this case. We seem to be doing the right
> > thing: i.e. we are passing the absolute URL to the proxy, and
> > asking the proxy to retrieve that object. Is the omission of
> > the error number for this case a "bug" in the HTTP spec?
Received on Monday, 27 April 1998 11:13:43 EDT

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