Re: Question on HTTP 408

On Wed, Jun 04, 2014 at 03:45:55PM -0500, Zhong Yu wrote:
> On Wed, Jun 4, 2014 at 1:46 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Wed, Jun 04, 2014 at 11:15:30AM -0500, Zhong Yu wrote:
> >> On Wed, Jun 4, 2014 at 10:28 AM, Willy Tarreau <w@1wt.eu> wrote:
> >> > On Wed, Jun 04, 2014 at 10:22:48AM -0500, Zhong Yu wrote:
> >> >> On Wed, Jun 4, 2014 at 7:49 AM, Willy Tarreau <w@1wt.eu> wrote:
> >> >> > Note the last sentence : "*If* the client has an outstanding request ...".
> >> >> > For me that clearly means that the client might very well receive a 408
> >> >> > while it did not have an outstanding request, which implies that no byte
> >> >> > was sent over the wire yet.
> >> >>
> >> >> How does the client receive the unprompted 408 reliably? Should the
> >> >> client be reading the inbound all the time?
> >> >
> >> > When it sends a request, it receives the unprompted 408 which was sitting
> >> > in the buffers, there's no desynchronization here. As Amos stated it, if
> >>
> >> I'm not sure how it works. Presumably the client has received server
> >> FIN before it starts to write the request.
> >
> > It needs to consume the response to be aware of the FIN.
> >
> >> This likely results in an
> >> RST, which destroys the client's inbound buffer as well.
> >
> > No, the RST is emitted if the server has totally closed (ie: the socket
> > buffers are destroyed and the socket orphan has been killed).
> 
> The server intends to kill the idle connection and free the resources,
> correct? Then the client will get RST when it tries to write to the
> connection;

No, it will first get the response which is already present in its
buffers, the RST will happen at best one RTT after the request is sent.
That's exactly why so many people were recently seeing the 408 in their
browser.

> if the client tries to read from the connection
> afterwards, it'll likely fail as well, depending on the TCP stack.

Once the RST reaches the client, it will fail. But before that the
pre-queued response will be delivered. And I don't see any reason
why a client would send, decide to wait an arbitrary delay, then
receive. The client sends the request and immediately polls for
receive, then it immediately gets the queued response.

> >> If the client is monitoring its inbound all the time for ahead-of-time
> >> response, we don't need 408 either - the server FIN serves the same
> >> purpose.
> >
> > No, the FIN alone tells you that anything happened, first thing being the
> 
> The FIN is received before the client writes the request. It's safe to
> infer that the request is not being processed the server.  A reasonable
> server will not close its outbound, then read and process another
> request.

The problem is not when the FIN reaches the client early. The problem is
that in many circumstances, this FIN will be sent in parallel to the late
request, and will then reach the client *after* the request was sent, while
it was sent *before* the request reached the server. That's the race Amos
was speaking about, and which is even documented in p1-6.5 :

   http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-26

   For example, a client might have started to send a new request
   at the same time that the server has decided to close the "idle"
   connection.  From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

Regards,
Willy

Received on Wednesday, 4 June 2014 21:55:51 UTC