httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: SIGPIPE handling
Date Mon, 09 Feb 1998 03:03:34 GMT
I'm not sure how well we can do in general.  Consider pipelined
connections -- we log a success even before we've flushed the last write.
Without affecting performance, we'd have to queue "completed" requests
until their last byte is written onto the net, and then do the logging.
(This could be considered a bug, it didn't occur to me until today
though.)

But remember that TCP applications are never sure that bytes they've sent
have actually made it across -- that information isn't returned by the
kernel.  You can write 100 bytes, which is buffered in the kernel, and
then the end client can close the connection after the write() has
returned.  You won't see that as an error in the 100 bytes you sent,
you'll see it as an error in subsequent read()s or write()s.

Even on persistant connections the presence of a subsequent request is not
an indication the client received everything, because of pipelining. 

In fact I submit that without something like
draft-faber-time-wait-avoidance-00.txt, the server can't always be certain
that the client got everything.  The client on the other hand, using
HTTP/1.1, is always certain it got the whole thing... modulo TCP checksum
errors where bogus packets happen to end up in the right checksum.

I'm not 100% certain of the above, but given what I've seen in practice I
think that what I'm saying is true... for Berkeley sockets implementations
at any rate. 

Dean

On Sun, 8 Feb 1998, Roy T. Fielding wrote:

> There are a number of applications areas for HTTP in which failure
> to deliver the entire content requested is a serious error.  Admins
> in such environments need to be able to see dropped connections in
> the error log, which is why we have those messages. Arguments to the
> effect of normal browsing behavior involves a lot of dropped connections
> do not apply, particularly since we don't log warnings by default.
> I agree that it would be better to have several levels of warnings,
> but we don't have that yet.
> 
> OTOH, our current handling of SIGPIPE is a separate issue.  SIGPIPE is
> too unreliable to be treated like a timeout, and isn't needed in any
> case provided that the errno is checked on writes (which we now do properly).
> 
> I think Dean's objection would be better handled by removing the SIGPIPE
> parts of the timeout handler and setting SIGPIPE to SIG_IGN thoughout.
> 
> ....Roy
> 


Mime
View raw message