- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 11 Aug 2010 19:17:05 +1000
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
This has been discussed a few times. Any indication of "I support pipelining" -- especially by intermediaries -- is going to lose its value as soon as somebody gets it wrong. Also, from what I've seen you can't rely on intermediaries to strip headers listed in Connection (unfortunately). Cheers, On 11/08/2010, at 4:56 PM, Thomson, Martin wrote: >> I agree the bad ones won't change but at least the client gets an >> indication that they don't work, exactly as with the Assoc-Req header. >> In fact in my opinion it becomes a way for an intermediary to >> explicitly >> declare support for pipelining. The currently broken ones won't >> announce >> it, that's fine, let's not pipeline with them. > > The only sort of indication that a client is likely to get for a bad proxy/server is the absence of any mechanism that is defined. > > So, if all we are looking to achieve is to indicate that the proxy (read: next hop) expressly supports pipelining, all you need to do is add a header: > > GET http://example.com/foo HTTP/1.1 > Pipeline: yes <-- read: please > Connection: pipeline > ... > > HTTP/1.1 200 OK > Pipeline: yes <-- read: OK > Connection: pipeline > > (Actually, you don't need the Pipeline header, just the connection token - the header contains no extra information.) > > Subsequent requests to that host can omit the token - you already know that pipelining is safe. > > That does the same as what you proposed with less mechanism. It doesn't address the bad intermediary problem, but it helps a client identify if pipelining is safe to attempt. > > --Martin -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 11 August 2010 09:17:12 UTC