Received: by taz.hyperreal.com (8.8.4/V2.0) id PAA03877; Mon, 24 Feb 1997 15:09:51 -0800 (PST) Received: from scanner.worldgate.com by taz.hyperreal.com (8.8.4/V2.0) with ESMTP id PAA03872; Mon, 24 Feb 1997 15:09:47 -0800 (PST) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.5/8.7.3) with UUCP id QAA11525 for new-httpd@hyperreal.com; Mon, 24 Feb 1997 16:09:45 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id QAA14808 for ; Mon, 24 Feb 1997 16:08:23 -0700 (MST) Date: Mon, 24 Feb 1997 16:08:23 -0700 (MST) From: Marc Slemko To: new-httpd@hyperreal.com Subject: Re: Apache PR#190: IdentyCheck and server accessibility In-Reply-To: <97022417161500@decus.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com 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.