httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Apache PR#190: IdentyCheck and server accessibility
Date Tue, 25 Feb 1997 06:57:12 GMT
On Mon, 24 Feb 1997, Chuck Murcko wrote:

> Sigh. The RFC (1413) says:
> 
>    The server should close the connection down after a configurable
>    amount of time with no queries - a 60-180 second idle timeout is
>    recommended.  The client may close the connection down at any time;
>    however to allow for network delays the client should wait at least
>    30 seconds (or longer) after a query before abandoning the query and
>    closing the connection.
> 
> I'd say a nonconfigurable timeout is a bug, and we should default to the
> minimum recommended, which is 30 sec. for a client. The user's firewall
> problems wouldn't seem to be ours to solve; he'll need to open up port
> 113 to make things work. That said, I default xinetd to 30 sec.

Not necessarily open it up, because better firewalls let you define what
to do when you get a packet on a certain port.  I have implemented, at
various times, sending a RST so it looks like there is no identd daemon
and redirecting traffic to my own that sends a fake response...

I think it is wise to ignore the RFC and go for 10 seconds at the most.
The thing is that we don't cache this, so 30 sec for every request (well,
it will hopefully only ask once per keepalive connection...) and since
this information should not be used for authentication anyway, I am
prepared to say if it takes more than 10 seconds too bad, as a default
until we can implement a config variable.  

OTOH, I think the whole concept of identd requests is silly for a
webserver, but... 

Man, Netscape's latest server beta is huge.  "wheee.... 65 megs for a web
server and we don't even have source."

> 
> Marc Slemko wrote:
> > 
> > On Mon, 24 Feb 1997, Rodent of Unusual Size wrote:
> > 
> > > >From the fingers of Jerry Morrison flowed the following:
> > > >
> > > >I turned on the IdentityCheck feature make server logs more informative.
> > > >(The identity info has a place in the standard server log format.)
> > > >
> > > >This worked fine on our server that's inside our firewall. But it made
our
> > > >server that's outside our firewall inaccessible, at least from inside
> > > >the firewall. E.g. it didn't answer requests for server info.
> > >
> > >     Are you sure it didn't answer, or just took a very long time to do
> > >     so?  If you enable IdentityCheck, the server contacts the client
> > >     system on port 113 to determine who's making the request.  The
> > >     server will wait for 60 seconds to get an answer.  If the client
> > >     system doesn't have a listener on that port (i.e., isn't running
> > >     [p]identd or a friend), the request will block for that duration.
> > >     If the page actually results in lots of separate requests, it may
> > >     appear that the server isn't answering.
> > 
> > 60 seconds is bogus.  My vote for changing it to 10 (before 1.2, IMHO).
> > It is true that there is a large overhead associated with it and it is
> > only useful in very limited situations, but 60 seconds is too much.
> > 
> > I think a configuration directive should be added to set the time (should
> > be a 5 line change), but NOT before 1.2.
> > 
> > >
> > >     One key to detecting this is that the browser will probably display
> > >     a status resembling, "server foo contacted, waiting for response."
> > >     If you wait long enough (up to N minutes for N requests), the page
> > >     will probably come through, and your access_log will show "unknown"
> > >     for the remote-user field.
> > >
> > > >Perhaps the IdentityCheck feature makes it wait forever on some info that's
> > > >blocked by the firewall.
> > >
> > >     In your particular case, the problem is almost certainly that a)
> > >     your client isn't running an RFC1413 listener, and/or b) your
> > >     firewall is blocking outbound connects to port 113.  Since it works
> > >     when the firewall isn't in the path, the latter sounds likely. ;->
> > 
> > In his case, I think the firewall is preventing connects from outside to
> > port 113 on the client.  A "good" firewall should proxy them or send a RST
> > in response like I normally setup mine to do so it times out right away.
> 
> -- 
> chuck
> Chuck Murcko
> The Topsail Group, West Chester PA USA
> chuck@topsail.org
> 


Mime
View raw message