Re: HTTP/2 vs. proxies ?

Eric and Matthew,

The discussion is welcome, but the speculation about people's motives is not. Please keep it technical and professional.

Thanks,


On 22 Jun 2014, at 11:16 am, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> 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/
> 

On 22 Jun 2014, at 10:21 am, Eric J. Bowman <eric@bisonsystems.net> wrote:

> Yes, from the outside looking in, it's quite clear that this is the
> first major Internet protocol being driven by corporate concerns rather
> than architecture. Focusing on the requirements of the next product-
> release cycle, to the exclusion of any concerns about how the Web would
> have collapsed under its own weight without intermediaries, quite
> naturally leads to the aversion we're seeing to T-E or anything else
> that slows down and fattens up the protocol in the name of universal
> interoperability.
> 
> The corporate concern is to go faster, my concern as a freelancer is
> free scaling, which we don't see with lesser corporate-driven protocols
> like WebSocket -- obviously, to me, a result of being on port 80 in a
> way which excludes intermediary participation. WS costs far more to
> deploy than HTTP/1.1, and if this winds up being the case with HTTP/2
> then it'll be just as "corporate" a solution as WS and HTTP/1.1 will be
> with us for a good while to come.
> 
> I'd say this one comes down to money. The big players have a financial
> stake in being able to use their size to dominate the market; the rest
> of us have loved HTTP caching for 15+ years now, because it levels the
> playing field. This issue manifests itself in "working with proxies",
> but I'd rather not kid myself about the real motivation for this break
> with the time-proven Taylor-school approach to Web architecture. I
> can't stress enough, if it ain't broke, don't fix it; intermediaries
> were the fix to what was broken before, why would anyone want to do
> away with it in this day and age for architectural reasons?

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 23 June 2014 02:33:10 UTC