- From: Mark Nottingham <mnot@mnot.net>
- Date: Sun, 5 Jun 2011 11:06:51 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 04/06/2011, at 3:32 PM, Willy Tarreau wrote: > If a connection dies during > an idempotent request, it's easy to retry it. POSTs are also sent over those > connections, at the risk of loosing them and having to retry them. In my > opinion, adding an "Expect: 100-Continue" header to those requests is enough > to ensure they are sent over a valid connection. But the issue remains when > there is an empty body with the POST, because if we set the Expect header > with the empty body, we'll cause a deadlock (or the server might notice it > and proceed anyway). > > So for empty POST requests, we still have no means of testing the connection > before reusing it. Or maybe by using chunked encoding and sending the 0<CRLF> > after 100 is received, provided the server accepts chunked encoded requests ? > > In fact, connection pooling becomes so much common nowadays that I think we > should ensure any implementation gets all corner cases right than just saying > they can't replay a POST over a broken connection, because they'll do stupid > or dangerous things to get it working anyway (and if you knew the number of > people I encounter who are amazed that a POST must not be blindly replayed...). I don't think we can generalise your pattern using Expect/continue, because clients can't always be sure that the next hop is 1.1. However, we could make it clear that it's OK for clients to retry non-idempotent requests when they have some sort of agreement (in-band, e.g., a protocol extension like POE, or out-of-band). Would that be workable for you? Regards, -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 5 June 2011 01:07:18 UTC