- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 07 Aug 96 13:40:09 MDT
- To: Paul Leach <paulle@microsoft.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>From: David W. Morris[SMTP:dwm@shell.portal.com] >On Mon, 5 Aug 1996, Jeffrey Mogul wrote: >> I think this leads to an ambiguous situation when the client is >> pipelining requests. We identified this ambiguity at the meeting >> we had in January of the persistent-connections subgroup. > >I think the ambiguity is also resolved if we change HTTP/1.1 to not >allow pipelining UNTIL the first server response is received accepting >the persistent connection and hence pipelining. I thought that this was already the rule. Did it get lost when we made persistence the default? Not lost, exactly. My recollection of the situation is this: The draft-*-06 spec does not require the client to wait before pipelining. Dave Morris asserted that this could cause problems; Roy Fielding asserted that it would not. Larry Masinter asked some people to consider the issue. My position was that I was not convinced by either side. I suggested that if Dave (or someone else) could come up with a specific example of how this would break, then I would be more sympathetic to his point of view. As far as I remember, nobody has provided such an example. Given that the "Proposed Standard" phase is the place to take this kind of risk, I felt it was not necessary to require the client to wait. Note that if waiting is actually unnecessary and yet the spec requires the client to wait, we are wasting an entire RTT on many (although not all) HTTP connections. I suggest that this would be a mistake. In particular, if you agree with me that the existing sticky-header proposal has the race condition that I believe it has, it would be possible to eliminate it either by requiring a client to wait before pipelining, or to use the three-way handshake that I described. But because of the extra RTT delay the former option imposes on pipelining, it seems preferrable to avoid it if possible. -Jeff
Received on Wednesday, 7 August 1996 13:49:55 UTC