httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: 2 bugs in 0.8.1
Date Tue, 18 Jul 1995 09:50:21 GMT
   Date: Tue, 18 Jul 1995 13:48:12 +0100 (BST)
   From: Mark J Cox <M.J.Cox@bradford.ac.uk>
   X-Sender: mjhcox@discovery.brad.ac.uk
   Precedence: bulk
   Reply-To: new-httpd@hyperreal.com

   I'm at a conference today so no time to fix these myself (from 0.8.1 on 
   hyperreal)

   1. mod_imap.c   SIGSEGV's if you try to get a map file without arguments
   (such as trying to use it from Lynx or typing in the URL of the map file)

Sigh...  (For now, it's probably adequate to just return SERVER_ERROR
in this case --- Randy, could you make the fix?).

   2. Authentication logging.  I remember this being talked about by
   Brian in the past.  If a request for a document is made using an invalid
   username the request still gets logged with the username set to whatever the
   user tried.  Shouldn't the auth field only get set for sucessful requests?

   x.brad.ac.uk - invalid_user_name [18/Jul/1995:13:37:42 +0100] "GET /rti/login/ HTTP/1.0"
401 808

Hmmm... this distinguishes requests which came in with bogus auth data
from requests which came in with none at all, a fact which my custom
log analyser uses --- for the most part, it prints out only highly
abstracted summary info, but there are events I want detailed reports
on, and requests with bogus auth information are among them.

Most 401 requests are not of interest (they're the ones where the
client sent *no* auth data, which is normal), but ones with bogus auth
data are, and it's nice to be able to tell which is which from the
transfer log.  I suppose I could do this with the error log as well,
but its format is a little too amorphous to handle automatically as
yet.

   So with Apache it's possible to try to log in as "lots of spaces" and then:

   x.brad.ac.uk - lots of spaces [18/Jul/1995:13:37:42 +0100] "GET /rti/login/ HTTP/1.0" 401
808

   Get's logged - somewhat messing up the CLF.

A problem, but a separate problem --- "lots of spaces" could actually
be legit (if not with the standard auth modules, then certainly with
someone's custom job).  This is a bug with the CLF spec itself, I'm
afraid. 

rst


Mime
View raw message