httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: Lingering close: a summary
Date Mon, 10 Feb 1997 00:20:29 GMT
On Sun, 9 Feb 1997, Ben Laurie wrote:

> Marc Slemko wrote:
> > 
> > I'm not sure you can say TCP is broken.  After all, lingering_close() does
> > exactly what we want.  If you want it at the API level, SO_LINGER working
> > as it should does it too.  TCP != the API.  The protocol itself isn't
> > necessarily broken.
> 
> But it consumes resources like crazy (i.e. a whole copy of Apache, and a
> network connection). A protocol level fix would be _much_ cheaper.

You are missing the point.  Just because the current API has no
close_but_don't_give_error_on_read_until_get_fin_from_client_and_don't_block() 
call does not make it a protocol issue.  If you add that call to the API
without changing one bit of the protocol, you no longer need to have
Apache hang around. 

> > > B. Don't close keptalive connections when we send an error. I'm sure
> > > there's a blindingly good reason we can't do this, but it escapes me. 
> > 
> > It can be done.  I suggested that the other day with a very small patch to
> > do that, and Alexei gave three reasons why it won't work without more
> > changes (for GETs; PUTs are another issue and are even more
> > complicated...). Those problems can be worked around without much trouble; 
> > if it had been brought up earlier, it would have been a good thing to do.
> > But it wasn't and I think it is a bit late for 1.2 now.  And this still
> > doesn't fix the whole problem, because it isn't just error messages that
> > can close the connection.
> 
> No. This issue is critical. I don't think we can rule out this kind of fix for
> 1.2.

The problem is that making errors keep the persistent connection open is
not enough to let us get rid of lingering_close. 

> > > C. Mandate in HTTP/1.1 that the first unsatisified request in an aborted
> > > keepalive session must be retried alone, or at least without pipelining,
> > > and explain carefully why. It would probably also be good to mandate
> > > that the connection should be closed after a timeout (from both ends). 
> > 
> > This isn't an overly clean solution.  If the client behaves this way, from
> > what I can see everything should work but I don't think this is a nice
> > solution.  This still does not allow for automatic retries of requests
> > that aren't idempotent.
> 
> You think that a half-close and reading an indefinite number of requests
> we are not going to service is "nice"? 

It is not an indefinite amount.  It is limited by the timeout and if the
client behaves correctly it should limit the number of requests.  The fact
is every solution can be called "not nice".

> > You also may be interested to note part of section 8.2 of RFC 2068:
> > 
> >    Upon receiving a method subject to these requirements from an
> >    HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
> >    respond with 100 (Continue) status and continue to read from the
> >    input stream, or respond with an error status. If it responds with an
> >    error status, it MAY close the transport (TCP) connection or it MAY
> >    continue to read and discard the rest of the request. It MUST NOT
> >    perform the requested method if it returns an error status.
> > 
> >    Clients SHOULD remember the version number of at least the most
> >    recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
> >    later response from the server, and it sees the connection close
> >    before receiving any status from the server, the client SHOULD retry
> >    the request without user interaction so long as the request method is
> >    idempotent (see section 9.1.2); other methods MUST NOT be
> >    automatically retried, although user agents MAY offer a human
> >    operator the choice of retrying the request.. If the client does
> >    retry the request, the client
> > 
> >      o  MUST first send the request header fields, and then
> > 
> >      o  MUST wait for the server to respond with either a 100 (Continue)
> >         response, in which case the client should continue, or with an
> >         error status.
> > 
> >    If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
> >    the server, it should assume that the server implements HTTP/1.0 or
> >    older and will not use the 100 (Continue) response. If in this case
> >    the client sees the connection close before receiving any status from
> >    the server, the client SHOULD retry the request. If the client does
> >    retry the request to this HTTP/1.0 server, it should use the
> >    following "binary exponential backoff" algorithm to be assured of
> > [...]
> > 
> > It goes on with some more interesting details.  Not all are applicable to
> > our situation, but they should be kept in mind.
> > 
> > 
> 
> So what's the problem? HTTP/1.1 already appears to mandate solution C, which
> leaves us clear to simply close the connection. Or did I miss something?

You need to carefully read the fine print.  I have not yet fully done so,
so I won't comment further right now, but I do not think this necessarily
gets us off the hook. 



Mime
View raw message