- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Tue, 30 Apr 2013 17:22:39 -0600
- To: IETF HTTP WG <ietf-http-wg@w3.org>
On 04/30/2013 01:40 PM, Willy Tarreau wrote: >>> A client [...] MUST NOT pipeline on a retry connection until it >>> knows the connection is persistent. >> Is it really possible to know that a connection _is_ persistent? > Well, it's by definition until a "connection: close" response is seen. You are right. My complains about not being able to know whether a connection is persistent were invalid because the rules in "p1 6.3 Persistence" determine whether the connection is considered persistent. However, there are two related problems with those rules: a) They do not apply to connections on which no responses have been received. b) They do not mention that a persistent connection may close without warning at any time. Let's start with (a): To know that a connection "is persistent", the client has to receive a response on that connection. This implies that the client MUST NOT retry a failed pipelined request on a connection it just opened. What if there are no other connections and not other requests to send, except for the failed one? Is the proxy going to be stuck because it is not allowed to use a new connection to retry the failed pipeline request? To fix this, I think we have to add a rule that declares a freshly opened, unused connection "persistent" OR allow retries on such connections without declaring them persistent. As for (b), depending on the intent of this MIST NOT, it may be useful to discourage developers from using connections that were idle for a long time for retries because those connections are more likely to fail when [re]used. Thank you, Alex.
Received on Tuesday, 30 April 2013 23:23:10 UTC