httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject YMB (yet more bugs)
Date Tue, 04 Apr 1995 18:08:05 GMT

BUG 1:

This is a weird one, one I had known existed in NCSA but I thought we had 
cleared up before but for some reason persists.

If you have a CGI script in a regular directory (because you enabled the 
.cgi type) and you give it a PATH_INFO of just "/", instead of executing 
the script it returns the text of the script.  This can be seen at

This is in an unauthenticated space so any of you should be able to see 
it.  I have DirectoryIndex set to "index" and Multiviews turned on.  
HOWEVER, on the exact same version running on hyperreal (modulo a few 
changes I made to the 0.4 running on hotwired that shouldn't have 
anything to do with this) this bug doesn't exist - check out

These is a script inlined on hyperreal's home page - the "/" doesn't 
affect this.

I can't think of any differences between the configurations I have for 
these setups.  Maybe SGI and BSDI have different responses when a stat() 
fails?  The log files are equally unhelpful (response code 200 for each, 
nothing in error_log).

BUG 2:  This is the second morning in a row I've come in and found dozens 
of httpd's running away with the CPU on hyperreal.  I don't have any idea 
how to tell what's causing the logjam - requests are still getting 
through very slowly, and those dozens aren't persistant, and a restart of 
the parent process allows those children to go through fine.  If someone 
with a hyperreal account wants to look at it again tomorrow morning 
when/if it happens that would be cool...

BUG 3:  Maybe not really a bug, but if I have MultiViews turned on and I 
hit a directory without specifying a file (i.e. the error_log records something like

[Tue Apr  4 11:03:59 1995] httpd: access to /export/pub/incoming/index 
failed for, reason: File not found; no multi in this directory

when in fact it generates an index just fine.  I'd prefer not to have the 
above situation logged in the error log, because it's not really an error.


View raw message