RE: HTTP/2 vs. proxies ?

I'll note that while changing the semantics of your setting to supplement, rather than replace, previously-sent values of the setting is perfectly legal (it's an extension, so you can change semantics if you need to), I really don't like having one setting that behaves completely differently than all of the others, and it doesn't seem critical to your goals.  That's why I made the setting a bitmask when I pulled your proposal into my draft's appendix.  However, a bitmask loses the ability to specify weights, which is needed for a strict replacement of HTTP/1.1 T-E.

Another option might be an (informative) frame type which gives weightings, but given the relative scarcity of frame types versus settings in the accepted version, I understand the desire to keep this in the setting space.

-----Original Message-----
From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Saturday, June 21, 2014 6:16 PM
To: Eric J. Bowman
Cc: Poul-Henning Kamp; HTTP Working Group
Subject: Re: HTTP/2 vs. proxies ?

Eric wrote:
> the only thing HTTP/2 is ready for is T-E,
which will only happen if, not when, the corporate interests jump on the interoperability bandwagon. So I'm sure HTTP/2 will go to last call without it, this is simply not the consensus view (although I question whether this would be the case if HTTP/2 were being developed by those who care about architecture over the corporate bottom line for the next quarter).

Speaking of T-E, and non-corporate interests, I've cobbled together something based on one of my original proposals for encoded/compressed DATA frames, taking advantage of the new extensibility model:
<https://datatracker.ietf.org/doc/draft-kerwin-http2-encoded-data/>

If there's interest I'm happy to hand it over to the wg, or to shuffle the ids up into the experimental ranges and keep it unofficial.

--
  Matthew Kerwin
  http://matthew.kerwin.net.au/

Received on Monday, 23 June 2014 17:35:38 UTC