- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 11 Aug 2010 14:07:48 +1000
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
Exactly. The properties that I'm looking for are ones that will make it safe from a browser vendor's perspective; i.e., they can deploy pipelining and not break existing sites (which they inevitably get blamed for). By making pipelining effectively opt-in through hinting, the decision is in the hands of the server administrator, not the browser. It's not an optimal situation, but it does give us the opportunity to realistically make the world better. Expecting intermediaries to suddenly get better is IME not realistic. Cheers, On 11/08/2010, at 11:27 AM, Thomson, Martin wrote: > Hi Willy, > > To me, hinting is the most important part. You need to know that a) the server and intermediaries that you are traversing wont break, and b) that there are no other problems with specific resources, like potential head-of-line blocking. > > As for the request ID, I think that Mark's succinct description works best: > > " > For example, if client A makes a request to a proxy cache with: > Req-ID: abc > and the proxy goes to the origin server and gets a response with: > Req-ID: abc > Cache-Control: max-age=300 > ...and then client B makes a request to the proxy cache with: > Req-ID: def > and gets the same response back from the cache (remembering that it hasn't been modified to support this), it'll get an error. > " > > If you go to the trouble of fixing the proxy to support pipelining (again, most do), then all you really need is some indication that it's safe to proceed, not a per-request header. > > The big challenge is with bad intermediaries and your plan seems to require that intermediaries change. The bad ones wont. > > --Martin -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 11 August 2010 04:07:59 UTC