- From: Thomson, Martin <Martin.Thomson@andrew.com>
- Date: Tue, 10 Aug 2010 14:00:34 +0800
- To: Willy Tarreau <w@1wt.eu>, Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Willy, > HTTP/1.1 200 OK > Request-Id: 3 > Connection: Request-Id > Content-length: 40 > > Any opinion ? There's a big difference between what you are proposing and what I understand Mark is trying to achieve. Anything that requires action from any entity is inherently not going to be necessary if all you are looking to do is make pipelining work. After all, if the implementer has the sophistication to deploy these sorts of mechanisms, then they can equally be told to stop mucking with pipelining requests. End of story; no new protocol mechanisms required. In part, this draft looks at ways for a server and client to collude in detecting bad intermediaries. There's not a lot that a document like this can do for bad servers aside from documenting some detection techniques - there certainly aren't any protocol mechanisms that you could deploy. My first reaction was to use a request identifier, but then that messes with caches that don't understand the new header. Going hop-by-hop, as you suggest runs afoul of the principle above. Personally, I wonder whether the judicious application of Content-Location and Content-MD5 would not be enough. It's close to what is suggested, but less definitive. If you want to talk about out of order responses, then we're in a whole 'nother ballpark. That's where discussion of SCTP, SPDY, HTTP/2.0, et. al. come in. --Martin
Received on Tuesday, 10 August 2010 05:58:53 UTC