- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Wed, 4 Jun 2014 15:45:55 -0500
- To: Willy Tarreau <w@1wt.eu>
- Cc: Michael Sweet <msweet@apple.com>, "William Chan (?????????)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matt Menke <mmenke@chromium.org>
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; if the client tries to read from the connection afterwards, it'll likely fail as well, depending on the TCP stack. > >> 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. > server crashed while processing your request, which is why the spec prevents > the client from retrying a non-idempotent request. > > Regards, > Willy >
Received on Wednesday, 4 June 2014 20:46:22 UTC