Re: Question on HTTP 408

On Wed, Jun 04, 2014 at 06:24:19PM -0500, Zhong Yu wrote:
> > 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.
> 
> Got it. However, RST is still very likely for requests with bigger
> payloads.

Yes, if the request is larger than 2 MSS (or more precisely doesn't
fit into the initcwnd), it will need at least one RTT and the RST will
be visible before it is sent.

> If a client wants to reliably receive unprompted 408s, it
> better proactively poll the inbound. In that case, I argue that FIN is
> as good as 408, because the client agent knows that the server closed
> the connection before the client sends (or is about to send) the
> request, therefore it's safe to retry the request.

It's safe if the FIN or RST arrives before the empty line marking the end
of headers is sent. If it was sent and some payload was being aborted, it
is not necessarily safe since it's very common for application servers
not to consume the whole request payload but just what they need, before
processing the request. However they must consume whatever the client
sends even after they send the response (cf p1-6.3). The problematic
use case I'm seeing is when an application server uses an HTTP auth
mechanism (typically Basic auth) accompanying a large request (eg:
you need to log in to upload a file or post a message in a webmail).
If the server detects a wrong password, it will increment the account's
bad attempts counter and return a 401 and possibly shutdown. Here the
client receiving the 401+FIN must not consider that it's safe to retry,
even if it arrives while it's sending the payload. And if the server
does not correctly drain the request and finally closes (very common
unfortunately), the client will get an RST at some point, so here again
the RST while sending the payload is not safe for automatic retry.

> We could argue that unprompted 408 is beneficial for most requests (of
> moderate size). However, if browsers need to be patched to take
> advantage of 408, they are better off to spend the effort to handle
> the more general case - proactively poll the inbound, discard the
> connection immediately if anything is received without a request
> (mostly FIN).

I completely agree that if any change needs to be applied, the first
one is to check the inbound first, eventhough I can understand that
it's easier to say than to apply to any existing code which was
architected based on a different sequencing. It will cover most use
cases and will only leave open the race where the server decides to
close at the same time the client decides to send. That said, when
you look at Matt's patches to make Chromium aware of the 408, I don't
think it would represent a huge effort to adjust clients to correctly
consider it.

Regards,
Willy

Received on Thursday, 5 June 2014 05:33:03 UTC