httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Countdown to 1.2b5
Date Sat, 25 Jan 1997 08:09:40 GMT
On Fri, 24 Jan 1997, Roy T. Fielding wrote:

> 1.2b5-dev status as of 9:15pm PST, Friday:
> 
>   * All Must-Do items have been applied.
>     Also committed: * suexec add TZ to allowed environment variables
>                     * disable the can_exec() when suexec() is enabled.
> 
>   * Time for me to get some sleep.  My changes to http_main.c are
>     getting backlogged while waiting for review. :(
> 
>   * Randy says he'll generate a tarball Saturday when we call for one.
>     Let's make it a deadline of 2pm Randy's time (12pm PST), since I'll
>     need to come into the office and commit some things first.
> 
>   * RobH wants us to test it before a public release. 
> 
> Should do before 1.2b5, if they get done by Saturday:
> 
>   * Select/accept parameter reinitialization
>        Status: patch posted, +1 Roy
> 
>   * patch to can_exec (util.c) that Randy says fixes something,
>     but he didn't say what and I can't tell from looking at it. :P
>        Status: patch posted, +1 Randy, Jim(?)  Did it get committed?

An alternative (and far simpler) solution was committed.

> 
>   * lingering_close generates the following error message
>       shutdown: Transport endpoint is not connected - lingering_close
>     using current 1.2b5-dev (only a few a day).  I think this is what 
>     happens when a client disconnects during transmission, which
>     is a normal condition for web servers.  I suggest not logging
>     an error if errno == ENOTCONN.
>        Status: no patch, Roy waiting on other change to http_main.c

But it isn't just a normal disconnect.  If it were there would be far more
of them.  Normally, when the client disconnects we get a SIGPIPE which
makes us call timeout(), and after we call timeout() we should never end
up in lingering_close.  

I think it may be if the client sends a RST to terminate the connection
(as per recent discussion on end2end-interest; _lots_ of connections are
terminated this way) and it gets here before we get to that point in
lingering_close.  If it sneaks in between when we last read or write the
socket and when we call lingering_close, I would expect that is what you
get.  But I would not know why they have gone up in frequency(?).  I think
it is worth leaving as is, at least for this beta.  If it is happening
often I would be interested in knowing.

> 
>   * accept errors EPROTO and ECONNABORTED should not be logged
>        Status: no patch, ditto above, but will require ifdefs

I guess.  I don't think those errors are worth completely discarding all
the time.  We really need the concept of multiple log/debug levels and
sane definitions for what goes where. 

> 
>   * Bad log message in mod_dir
>        Marc Slemko wrote: if permission is denied for the index file
>        it will log a message in the error log for each and every one of the
>        'DirectoryIndex'es.  Perhaps another ifdef wrapped if that doesn't
>        log the message if the error is EACCES...
>  
>        And as I mentioned before I hate the log message:
>  
>           log_printf(r->server, "access to %s failed for client; unable to
>           determine if index file exists (stat() returned unexpected
>           error[%d])", r->filename, errno);
>  
>        that I wrote.
> 
>        Status: A patch is needed, since I've seen this message while testing
>                a prior bug fix and it really is useless.

A suggested patch has been sent to the list.



Mime
View raw message