- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 4 Jun 2014 20:46:58 +0200
- To: Zhong Yu <zhong.j.yu@gmail.com>
- 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 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). > 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 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 18:47:30 UTC