Re: Question on HTTP 408

On 4/06/2014 11:52 p.m., Michael Sweet wrote:
> Willy,
> 
> On Jun 4, 2014, at 12:42 AM, Willy Tarreau wrote:
>> Hi Michael,
>> 
>> On Tue, Jun 03, 2014 at 07:54:18AM -0400, Michael Sweet wrote:
>>> William,
>>> 
>>> This sounds like a pretty obvious bug - a HTTP server only
>>> responds when it has received something.  The usual keep-alive
>>> timeout of connections is silent (server just closes the
>>> connection, with a preceding TLS shutdown for HTTPS).
>> 
>> Please could you check my other response to Roy ? In short I do
>> instead think that responding 408 is the only way to gracefully
>> shut down *and* inform the client it can safely retry and I really
>> think it was designed for this exact purpose.
> 
> I don't think it was designed for being returned when no request had
> started coming in, but rather when a partial request was received and
> then timed out.  There is nothing in any of the HTTP RFCs that talks
> about returning a response line, headers, and message body to the
> client without first receiving something from the client.

In counterpoint I don't think HTTP/1 was designed for the model of
opening TCP connections then leaving them unused for up to 60 minutes
with no request.

* In the IPv6 network environment we have ongoing issues with PMTUd
brokenness from admin A wrongly disabling all ICMP traffic and admin B
some networks away sending traffic over a tunnel or hop with MTU
restructions. What this looks like to HTTP intermediaries on the
receiving end (CDN reverse-proxies etc) is a connection where no request
was ever sent.

* There are similar well-known issues with ECN and Window Scaling that
result in the same behaviour. And any number of other future or weird
TCP level issues may come up at any time preventing a mid-flight request.

* Bad/mistaken end-user configuration resulting in any server-initiated
protocol such as FTP or SMTP being incorrectly directed at the HTTP
proxy result in hung connections. A client sitting waiting for server
HELO wastes resources and is not easily debugged.

* Then there is RTT race conditions on idle connections of any type
(used or not). The request may be half written and in-flight when the
server end closes on a long timeout. What then is the client expected to
do? if the request was pipelined a bad choice of reaction could
seriously break the client applications expectations.


If the intermediary waits for a few minutes then sends a small 408
followed by immediate termination there is some chance that the client
will be able to recover from a lost request which was sent but never
received. At the very least it adds visible clues to the troubleshooting
process fingering the problem.

RFC2616 requires that recipients treat such unexpected bytes as garbage
and mandated connection close. Using a valid HTTP/1.1 408 instead of
actual garbage/RST/FIN allows the recipient to treat it as response to
any sent request and fixes the pipeline race issue.


PS. Squid is not (yet) doing this 408 behaviour as HAProxy but it has
been on the todo list for some time for all the above reasons.

Amos

Received on Wednesday, 4 June 2014 13:30:37 UTC