Subject: HTTP/2 vs. proxies ?

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 21 Jun 2014 16:52:53 +0000

In message <CABkgnnX9+sf=[email-masked]>
, Martin Thomson writes:

>We killed it so that we could avoid having to talk about it any more.
>That worked out well, didn't it?

I'm increasingly getting the feeling that we have people who like
the HTTP/2.0 draft and people who work with proxies, and that those
two sets are almost exclusive ?

I would be interesting to see what a straw-poll of these two
questions would show:

A)  I think HTTP/2.0 is ready for last call		YES/NO

B)  My primary HTTP/2.0 interest is proxy technology	YES/NO

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sat, 21 Jun 2014 18:21:20 -0600

> two sets are almost exclusive ?

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?

> A)  I think HTTP/2.0 is ready for last call		YES/NO

No, 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).

> B)  My primary HTTP/2.0 interest is proxy technology	YES/NO

I'd state that my primary concern with HTTP/2 is, and always has been,
that the ability of intermediaries to participate in client-server
communication be preserved. Otherwise we regress architecturally, back
into known problems with scaling which can otherwise only be overcome
by those with deep pockets -- the very corporations driving development
of this protocol, who don't share this concern with those marginalized
here.

-Eric

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 22 Jun 2014 11:16:05 +1000

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/

---

From: Cory Benfield <[email-masked]>
Date: Sun, 22 Jun 2014 08:23:44 +0100

> the ids up into the experimental ranges and keep it unofficial.

This looks like what I was hoping to see from extensions, personally. 
I’ll happily implement that in hyper regardless of whether it gets 
handed over to the WG.

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 22 Jun 2014 19:42:47 +1200

> I’ll happily implement that in hyper regardless of whether it gets 

Same here.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jun 2014 12:32:37 +1000

Eric and Matthew,

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

Thanks,

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Jun 2014 17:34:48 +0000

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: [email-masked] [mailto:[email-masked]] 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 ?

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

---

From: Jason Greene <[email-masked]>
Date: Mon, 23 Jun 2014 13:19:41 -0500

> B)  My primary HTTP/2.0 interest is proxy technology	YES/NO

I have been concerned about the protocol cost in a load balancing / proxy perspective, and how that will impact throughput on commodity hardware. In particular, on top of the framing cost, I am a little concerned with the CPU cost of differential compression in a proxy setting (for reasons previously stated). However, since less physical bytes are required to be on the wire than in HTTP/1.1 it very well could be a wash. Commodity hardware is also getting quite powerful when you consider its not too expensive to get a system capable of 40 threads near 3ghz, so a ballpark of 96 clock cycles per byte if you have 40gb.

I wish I had the time to build an implementation to verify equivalent HTTP/1.1 throughput levels before the spec goes into last call, but unfortunately I was a late to the party. I am hopeful that any deficiencies in this area could be addressed in a followup HTTP/3 spec.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: [email-masked]
Date: Mon, 23 Jun 2014 17:33:42 -0400

For encrypted traffic, forward proxies are functionally bypassed and most HTTP/2 traffic will be encrypted. When they do see the rare plaintext attempt to upgrade to HTTP/2, proxies can simply strip the header and prevent it. Therefore proxies have little motivation to implement it. HTTP/2 with mandatory TLS (the Google and Mozilla position) is an attempt to obsolete forward proxies, which explains why lack of proxy support in HTTP/2.0 is not a blocking issue to go to last call.

Thanks,

Peter

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 23 Jun 2014 22:23:30 +0000

In message <[email-masked]>, [email-masked]
om writes:

>HTTP/2 with mandatory TLS (the Google and Mozilla 
>position) is an attempt to obsolete forward proxies, [...]

Even if that was a defensible position, forward proxies are not the
only kind of proxy.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 23 Jun 2014 22:39:53 +0000

I know a lot of organisations that will just block anything they cannot 
control.

So to consider it viable that there be no room for forward proxies in 
the internet of the future is a position that is not particularly 
well-connected with reality.

All the move to TLS did was promote the deployment of MiTM, and slow 
things down quite a bit.

------ Original Message ------
From: "[email-masked]" <[email-masked]>
To: "Poul-Henning Kamp" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 24/06/2014 9:33:42 a.m.
Subject: Re: HTTP/2 vs. proxies ?

>For encrypted traffic, forward proxies are functionally bypassed and 
>most HTTP/2 traffic will be encrypted. When they do see the rare 
>plaintext attempt to upgrade to HTTP/2, proxies can simply strip the 
>header and prevent it. Therefore proxies have little motivation to 
>implement it. HTTP/2 with mandatory TLS (the Google and Mozilla 
>position) is an attempt to obsolete forward proxies, which explains why 
>lack of proxy support in HTTP/2.0 is not a blocking issue to go to last 
>call.
>
>Thanks,
>
>Peter
>
>>  In message 
>><CABkgnnX9+sf=[email-masked]>
>>  , Martin Thomson writes:
>>

---

From: Peter L <[email-masked]>
Date: Mon, 23 Jun 2014 18:43:21 -0400

I agree. But I think increased MITM will be an unintended consequence.

Peter

> On Jun 23, 2014, at 6:39 PM, "Adrien de Croy" <[email-masked]> wrote:
> 
> 
> I know a lot of organisations that will just block anything they cannot control.
> 
> So to consider it viable that there be no room for forward proxies in the internet of the future is a position that is not particularly well-connected with reality.
> 
> All the move to TLS did was promote the deployment of MiTM, and slow things down quite a bit.
> 
>

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 24 Jun 2014 10:29:44 +1000

On 24 June 2014 03:34, Mike Bishop <[email-masked]> wrote:

> 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.
>
>
Another alternative is one setting per encoding, although that's a bit
silly. (Come to think of it, that was how it ended up in the HTTP2 draft
before being yanked -- one setting for GZIP).

In any case I think it's appropriate to make an effort, at least for the
first few extension-type discussions, to try and set the tone right. If we
think there's more value in promoting the idea that settings should keep
the "replace" semantic, I'll try to work my draft to fit.

​Incidentally, this still isn't a strict replacement for T-E because I
can't stack encodings, and because 256 rank levels is fewer than 1001, and
I have no support for other parameters, etc. It might be worth me adding an
explicit acknowledgement of the differences.

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 24 Jun 2014 16:09:52 +1200

> I agree. But I think increased MITM will be an unintended consequence.

AIUI, the editors have decided to go ahead in compliance with RFC2804 by
ignoring the considerations for wiretapping.

Sadly the choice of ignoring seems to implicitly mean that the spec does
not do anything to discourage the underlying factors driving wiretapping
interception of HTTP(S).

Amos

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 24 Jun 2014 05:00:17 +0000

wiretapping is yet another issue.  The difference between a government 
agency wiretap, and a commercial organisation's MITM proxy, is that one 
is covert, and the other can usually be overt.

I thought the basis of the decisions / conclusions about wiretapping in 
2804 were related to the issues around covert wiretapping and government 
agency directives, rather than overt interception for other purposes.

If we had a proper mechanism to allow overt with opt-in consent for 
interception, would 2804 even apply?