W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Question on HTTP 408

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>
Message-ID: <20140604184658.GC3154@1wt.eu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC