Subject: Re: Encouraging a healthy HTTP/2 ecosystem

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 07:14:46 +0000

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

>I appreciate you're concerned about the CONTINUATION issue, but using it 
>to derail other discussions isn't appropriate. 

This is very much a discussion about CONTINUATION:  The proposal is
to abuse market dominance to force CONTINUATION to be implemented
where it is neither needed nor desired.

If you prefer, I can use the term "mafia-methods" rather than "blackmail" ?

-- 
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: Mark Nottingham <[email-masked]>
Date: Tue, 1 Jul 2014 17:44:08 +1000

> where it is neither needed nor desired.

As Will said, it was very clearly qualified with "If we think..."   That was an invitation to a discussion, not an ultimatum. 

> If you prefer, I can use the term "mafia-methods" rather than "blackmail" ?

Your word choices can be amusing, and that seems to get you lots of readers in places like your ACM Queue articles.

Here, however, they're causing distractions, and the IETF process is very clear about that. BCP54 makes it clear that we argue the proposals, not attack the person (or intimidate them). Saying that a suggestion is "blackmail" isn't arguing the proposal, it's smearing the proposer.

Keep in mind that you're arguing on the side that's saying they won't correctly implement an open standard if this feature is included -- and no one has yet accused them of bad behaviour as a result. All that I ask is that you grant the same benefit of the doubt that those you disagree with give you.

BCP83 goes on to say that "good faith disagreement is a healthy part of the consensus-driven process." You're welcome to disagree, but please do so in good faith.

Thanks,

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

---

From: Cory Benfield <[email-masked]>
Date: Tue, 1 Jul 2014 09:04:55 +0100

Leaving the CONTINUATION discussion to one side for the moment...

On 1 July 2014 04:37, William Chan (陈智昌) <[email-masked]> wrote:
> * In order to encourage sites to do feature detection as opposed to UA
> sniffing, it'd be nice if major client implementations, some percentage of
> the time, choose not to negotiate HTTP/2.

In principle this is a great idea. In practice this worries me a bit.
You'll need to get all the browser vendors to agree to do this, and to
agree to do it in roughly the same way, or you'll all start competing
on how to do this in the most performant way (or indeed all just
abandon it). The client library implementations will certainly not do
this, for obvious reasons.

> * In order to prevent the extension mechanism from failing (due to
> intermediaries whitelisting extensions and disallowing all others, or some
> other sort of brokenness), it'd be nice for clients to negotiate random
> dummy extensions and, using out of band knowledge shared with the server,
> require that those extensions be negotiated. More than just negotiated,
> these extensions should probably use dummy logic like sending bogus
> extension frames and settings. A vendor that owned both an auto-updating
> client and popular website could enforce this.

So, just Google then. _Maybe_ Mozilla depending on how Apache ends up
exposing HTTP/2. ;)

All jokes aside, this is a perfectly reasonable thing for Google to
do, but it's unlikely to be anything anyone else can also do. Not a
bad idea though.

> * Make sure to use features that aren't necessarily required, in order to
> make sure they remain viable. For example:
>   - If we think servers need to at least be able to support reading
> continuation frames (if not necessarily use them themselves), then clients
> should make sure to exercise this code path some part of the time.

Good luck with this one, I'm certainly not touching it with a ten-foot
pole. As I've said before, compatibility is hugely important to me.
I'm much happier restricting myself to the subset of features that are
necessary and guaranteed to be implemented. I'm not going to emit
CONTINUATION frames unless I absolutely have to, because the risk of a
server or intermediary blowing away my connection is too high. If that
happens, I'm going to be the one that gets blamed. The risk is just
too high for too little reward.

While we're here, what about HTTP/1.1 Upgrade? I know that Chrome and
FF have said that this isn't going to be supported by them: does that
remain true? I worry that this section of the spec will be left out by
a lot of people (I haven't implemented it yet), which makes it an easy
bit of the spec to just have atrophy away.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 09:02:12 +0000

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

>Keep in mind that you're arguing on the side that's saying they won't 
>correctly implement an open standard if this feature is included 

1. There's no standard, there's a draft.

2. I've never promised to implement HTTP/2 at all.  I've said I'll do it
   if it proves worthwhile for me and my users.

3. If and when I implement HTTP/2, I'll have to balance the concerns of
   my users against being 100% compliant with bad ideas in the standard.

   For instance the current draft mandates DoS-vulnerabilities like this:

	  "Any number of CONTINUATION frames can be sent on an existing stream"

   Varnish is never going to "correctly implement" that, *ever*.

>BCP83 goes on to say that "good faith disagreement is a healthy part of 
>the consensus-driven process." You're welcome to disagree, but please do 
>so in good faith.

I participate in good faith:  Even before the first draft were
launched I pointed out the most severe of the shortcomings it still
suffers from, and from the very start I challenged the accelerated
time-schedule proposed which left a messed up prototype as the only
realistic candidate.

What seems obvious, is that other concerns, whatever they might be
and whoever might harbour them, are far more important than producing
a good protocol that will do its job well for a long time.

Yes, I still think that the HTTP2 draft should get Last Rites rather
than Last Call.

But failing that, I want see major bogosity, such as CONTINUATION
and all the priority crap moved to extensions, so they can be
negotiated, avoided and get a chance to prove their own worth
in open competition with other proposals.

Even more I'd like to see a simple sane change which would simplify
and shorten the protocol specification dramatically, increase the
performance significantly and overall increase the chances that
implementing HTTP/2 would be worth my or anybody elses time.

Poul-Henning

---

From: Patrick McManus <[email-masked]>
Date: Tue, 1 Jul 2014 08:00:19 -0400

On Tue, Jul 1, 2014 at 4:04 AM, Cory Benfield <[email-masked]> wrote:

> remain true?

That's still true. (speaking for myself and that is how I understand
Chrome's plan.)

---

From: Jason Greene <[email-masked]>
Date: Tue, 1 Jul 2014 10:09:04 -0500

On Jun 30, 2014, at 10:37 PM, William Chan (陈智昌) <[email-masked]> wrote:

>  - If we think servers need to at least be able to support reading continuation frames (if not necessarily use them themselves), then clients should make sure to exercise this code path some part of the time.

If you are really going to mandate that implementations fully support CONTINUATIONS then they need to *at least* be limited by default, and negotiated from there. 

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 1 Jul 2014 13:00:17 -0700

Let's be clear here - we don't want to have a spec that doesn't mirror
reality. If the spec says that something is a core feature, then it's
terrible for it to fail to interop depending on which implementation you
are speaking to.

I think it's a completely fair argument to discuss whether or not
CONTINUATION frames should be a core feature in the spec, or punted off to
be negotiated instead or something. But *if* we keep it as a core part of
the spec, it really must work, and I think it'd be healthy for the
ecosystem if major implementations moved first to exercise as much of the
spec as possible in order to prevent these kinds of interop issues from
appearing.

Please don't hijack this thread to make your debates about CONTINUATION
frames. There are plenty of other threads for that already.

On Tue, Jul 1, 2014 at 8:09 AM, Jason Greene <[email-masked]>
wrote:

> If you are really going to mandate that implementations fully support
> CONTINUATIONS then they need to *at least* be limited by default, and
> negotiated from there.
>
> --
> Jason T. Greene

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Jul 2014 22:08:34 +0200

> spec as possible in order to prevent these kinds of interop issues from

William, I tend to disagree with you on this argument. Just because RFC2616
did not impose limits on header size, it does not mean that implementations
would have to support unbounded lengths. If the sole purpose of CONTINUATION
is to support headers larger than 16383 bytes, then any product which is not
able to support more than this size of headers will have no use of CONTINUATION
and will not even be able to deal correctly with them, so it better not try to
implement them and do stupid things.

For example, haproxy is built by default with 16kB buffers, 15 of which can
receive headers. I'm not seeing any use in implementing continuations and
risk to break everything because of their significant extra complexity. Still
it's not the lack of continuations which causes the interop issue, but simply
the lack of support for more than 16kB headers. Every implementation has some
limits at some points.

Regards,
Willy

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 1 Jul 2014 13:19:46 -0700

> implement them and do stupid things.

It's not quite the same because even if you want to reply to requests
with more than 16k of headers with an HTTP 431 for example, you don't
necessarily want to tear down the connection so you can reply to other
outstanding requests or accept new ones.

This means that you must process that CONTINUATION frames since they
can update the HPACK header table. You can of course discard the
headers fields.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Jul 2014 22:31:33 +0200

> outstanding requests or accept new ones.

I mean at least in 1.1, in practice you generally do so because if your state
machine has reached the end and is not able to parse the headers past the end
of the buffer, and you can't always recover. Still that situation is acceptable
since it should almost never happen, all you need is to report it and log it.

When you reject a client on such a condition, you generally don't expect that
client to strip off cookies, referer, user-agent or whatever, so definitely
deny it any further access, and your connection becomes really useless. This
is a serious protocol error which is hard to recover from, so if you break the
connection it's not a big deal.

> can update the HPACK header table. You can of course discard the

As I said above, all that dangerously complicated stuff for a dead
connection anyway is not worth it. Better kill the connection and restart
with something sane if needed.

Willy

---

From: Jason Greene <[email-masked]>
Date: Tue, 1 Jul 2014 15:32:32 -0500

On Jul 1, 2014, at 3:00 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Let's be clear here - we don't want to have a spec that doesn't mirror reality. If the spec says that something is a core feature, then it's terrible for it to fail to interop depending on which implementation you are speaking to.
> 
> I think it's a completely fair argument to discuss whether or not CONTINUATION frames should be a core feature in the spec, or punted off to be negotiated instead or something. But *if* we keep it as a core part of the spec, it really must work, and I think it'd be healthy for the ecosystem if major implementations moved first to exercise as much of the spec as possible in order to prevent these kinds of interop issues from appearing.
> 
> Please don't hijack this thread to make your debates about CONTINUATION frames. There are plenty of other threads for that already.

How is this hijacking your thread? You used CONTINUATION as a specific example, and as far as I can tell it was the impetus. 

Although my point isn’t specific to CONTINUATION. My point is simply that if you are going to create some compliance black/white list, you need to ensure that you have fair criteria, and that also means ensuring various open ended aspects of the specs (such as allowing infinite data) are changed to specify the constraints you intend to enforce. Otherwise the its a purely subjective matter.

---

From: Johnny Graettinger <[email-masked]>
Date: Tue, 1 Jul 2014 16:46:15 -0400

> with something sane if needed.

If HAProxy is speaking HTTP/2 to backend application servers, and I can get
an application server to send a response with more than 16K of headers,
doesn't that give me an easy way to tear-down any other active stream to
that server?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 20:50:28 +0000

>with something sane if needed.

Seconded.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Jul 2014 22:55:26 +0200

> doesn't that give me an easy way to tear-down any other active stream to

In 1.1 it would return 502 bad gateway. In 2.0, assuming I manage to implement
it to the server, I don't expect it to be able to multiplex multiple streams
over a single connection before we've finished HTTP/3. I'm serious. 2.0 is a
major architecture change for low-level intermediaries. So I'd say that for
now, with the elements I have, a protocol error on 2.0 will be handled the
same way as in 1.1 : the connection will be torn down and the effects will be
exactly the same : only the request using that connection will be impacted.

I'm not saying nothing better could be done, of course. But at least for me
right now it's not obvious :-/

Willy

---

From: James Adjamli <[email-masked]>
Date: Tue, 1 Jul 2014 21:55:01 +0100

Hello all,
I have been in this mailing list for sometime now, and will appreciate if I
can be oriented so as to contribute meaningfully.
James
KNUST Caucus
ISOC Ghana
+233(0)248814328

James
+233(0)248814328
On Jul 1, 2014 8:49 PM, "Johnny Graettinger" <[email-masked]>
wrote:

> If HAProxy is speaking HTTP/2 to backend application servers, and I can
> get an application server to send a response with more than 16K of headers,

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 1 Jul 2014 14:04:16 -0700

> exactly the same : only the request using that connection will be impacted.

What we do:

1) HPACK is configured to stream headers and discard all headers above
a certain side (see github.com/twitter/hpack decider maxHeaderSize).
2) The reverse proxy aggregates the response headers and if it they
have been truncated (because they were above the max size) it responds
with a 502.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 1 Jul 2014 14:08:03 -0700

On Tue, Jul 1, 2014 at 1:32 PM, Jason Greene <[email-masked]>
wrote:

> How is this hijacking your thread? You used CONTINUATION as a specific
> example, and as far as I can tell it was the impetus.
>

It's hijacking my thread because it wasn't the impetus :) Indeed, as I
already said, I specifically caveated the CONTINUATION case because I knew
it was contentious. The impetus is because I've received word of MITM
proxies that plan to do deep inspection of HTTP/2. So I'm becoming worried
about ossification on these TLS connections that were previously free from
intermediary interference. If they move first, then we can't move later in
incompatible ways with these intermediaries. Therefore, I think it's in our
interest to make sure that whatever part of the protocol we think is
important to preserve for use should be actively exercised. And
CONTINUATION would only be one example of such a thing if we decide to keep
it. I purposely tried to avoid that discussion by caveating it, but I now
see my error in even mentioning it because everyone else has seemed to
latch onto it and hijacked this thread :(

> Although my point isn’t specific to CONTINUATION. My point is simply that
> if you are going to create some compliance black/white list, you need to
> ensure that you have fair criteria, and that also means ensuring various
> open ended aspects of the specs (such as allowing infinite data) are
> changed to specify the constraints you intend to enforce. Otherwise the its
> a purely subjective matter.
>
> --
> Jason T. Greene

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Jul 2014 23:09:31 +0200

> have been truncated (because they were above the max size) it responds

But what do you do then with the server connection and/or stream when
you send the 502 to the client ?

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 21:23:49 +0000

In message <CAA4WUYhOu0tW_9vSJ4wcLh+V=[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF
uICjpmYjmmbrmmIwp?= writes:

>The impetus is because I've received word of MITM
>proxies that plan to do deep inspection of HTTP/2. 
> [...]
>Therefore, I think it's in our
>important to preserve for use should be actively exercised.

And what if the MITM proxies disagree with you about which parts of
the standard deserve to work and block some of them ?

What will you do ?

Pop-up: "EXAMPLE.COM don't agree with Jason Greene about HTTP/2 scope" ?

Penalize them by deliberately slowing down their traffic ?

It's a much better idea to make the core protocol so simple that all
bits of it are naturally exercised.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 1 Jul 2014 14:29:25 -0700

On Tue, Jul 1, 2014 at 2:23 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CAA4WUYhOu0tW_9vSJ4wcLh+V=
> [email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF

> What will you do ?

Hard fail. User visible error. End users blame the last mover, therefore we
should move first *if we believe that the functionality is important to
preserve*. In my example about extensions, assuming we think extensibility
should be preserved (I've not heard recent disagreement here, but if I'm
wrong that there's not consensus here, please raise), then we should hard
fail when the extension negotiation fails. Hence attempting to negotiate
dummy extensions and use dummy extension frames to see if they make it
through.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 2 Jul 2014 00:01:43 +0200

> dummy extensions and use dummy extension frames to see if they make it

The problem is that there's no "dummy" extension, the extension you'll
try to negociate will be assigned later and you may end up accidentely
negociating something that modifies the framing or anything just because
at the time you do this you're not aware of this. Imagine that we implement
jumbo frames this way. I'd rather not see the TCP Window Scaling mess again
where many firewalls didn't look at the option but still used to analyze
sequence numbers and to block traffic when they looked out of window!

It's important for interoperability not to send undefined crap over a wire
because what's underfined for the agent doing it may be defined for the
one receiving it.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 22:38:15 +0000

In message <[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF
uICjpmYjmmbrmmIwp?= writes:

>Hard fail. User visible error. End users blame the last mover,  [...]

This is why I called the proposal "blackmail".

I think HTTP/2 should strive to be such a good protocol that people will
want it, rather than try to intimidate any dissent with thinly veiled
"Nice website you have here, pity if anything happened to it..." threats.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 1 Jul 2014 15:49:08 -0700

On Tue, Jul 1, 2014 at 3:38 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <
> [email-masked]>,
> =?UTF-8?B?V2lsbGlhbSBDaGF

Hm, I don't follow. I'm not sure if we disagree in our logical conclusions,
or that we're starting from different premises and have different
fundamental assumptions. Let me try the latter. I assume that the inability
to reliably deploy new TCP options (due to middlebox interference) is a bad
thing. Do you disagree with this?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 01 Jul 2014 23:07:07 +0000

In message <CAA4WUYjHU__T9TT868mory=szszgXH3SCbod+F7=[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF

>thing. Do you disagree with this?

A bad analogy is like a wet screwdriver:  TCP options are not
information carrying (unless you're truly evil that is...)

The reason many of the MITM proxies are there, is to filter out
or prevent information not in compliance with a particular policy.

Do you think that policy normally is going to have "allow through
anything I don't understand" clause ?

Have you not noticed how many "guest" WLANs only allow traffic on
port 80 and 443, but not, for instance on port 22 ?

What makes you think HTTP/2 is going to escape that mindset ?

If your attempt to force negotiation of random extensions through
blackmail methods succeeds, it would amount to a "Get out of jail
cards" for any HTTP content filter that bows to your mob rule.

Do you seriously think the library, school, jail or country (UK:
I'm looking at you!) would instantly see the errors of their ways
and remove their illadvised filters ?

I think they'll just ban HTTP/2 from their network until they can
filter it, and that filter is going to nix anything not on its
white-list, no matter what you would like.

There are never any easy techical fixes for hard political problems.

---

From: Adrian Cole <[email-masked]>
Date: Tue, 1 Jul 2014 19:03:47 -0700

> That's still true. (speaking for myself and that is how I understand
Chrome's plan.)
Same is true for the okhttp android client.

---

From: James M Snell <[email-masked]>
Date: Tue, 1 Jul 2014 20:36:18 -0700

Alternative suggestion that would likely be much more effective:

1. Don't fast track http/2 to last call. We collectively need more
widespread implementation experience. It's perfectly OK to let the
implementation draft sit for a while before pushing to RFC. If those of you
who favor the current draft as being complete and ready to go are confident
in your positions, then surely patience won't cause a problem, right? Who
knows, it might actually save us some trouble down the road on http/3.

2. Simplify more. Things like CONTINUATION are needless complication. Other
bits qualify as premature optimization. Remove those bits, define a proper
end to end extensibility model, encourage active experimentation and
finalize later on the bits we can reasonably agree will actually work.

3. Deal with intermediaries as first class citizens in the protocol. They
are a really that will not go away and cannot be worked around.

- James
On Jun 30, 2014 8:40 PM, "William Chan (陈智昌)" <[email-masked]> wrote:

> This has come up in a number of different discussions over time, and I
> thought it'd be nice to gather a list of things that it'd be useful if
> major implementations did in order to keep the ecosystem healthy. My
> interest is that, before lots of other vendors start implementing HTTP/2
> and we start getting a plethora of crappy implementations doing dumb things
> and see actual deployment, we try to enforce good behavior so that when
> they deploy and do stupid things, it breaks for them. I don't want HTTP/2
> to ossify the way that TCP options have essentially become undeployable.
> Here are some ideas for things to do:
>
> I feel like there were a number of other things that we wanted to do, but
> I forget. If anyone knows anything that they want early implementers to do
> in order to keep the ecosystem healthy, I'd love to hear.
>
> Cheers.
>
>
>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 1 Jul 2014 23:44:46 -0700

> This is why I called the proposal "blackmail".

Let's be clear here - you're the one blackmailing. You're threatening to
deliberately violate the spec if you don't like it.  Will is simply making
sure that the (hopefully accidental) violator of the spec is properly
identified so that the bug can be easily fixed.

> "Nice website you have here, pity if anything happened to it..." threats.

You mean like get google, facebook, twitter, and thousands of other sites
to implement it before its even accepted as a standard?  Done!  let's move
on.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Tue, 1 Jul 2014 23:55:11 -0700

On Tue, Jul 1, 2014 at 8:36 PM, James M Snell <[email-masked]> wrote:

> 2. Simplify more. Things like CONTINUATION are needless complication.
> Other bits qualify as premature optimization. Remove those bits, define a
> proper end to end extensibility model, encourage active experimentation and

We can wait longer, or we could throw out this spec and start over, but
these arguments won't go away. Any protocol, given this group of folks will
have some number of disagreements about what features should be in or out.
 So in this case, I don't think waiting is a path to resolution.

But I don't mean to take your comment lightly.  I actually did wrack my
brain searching for empirical methods to decide "when is the protocol
ready".  Would it be a certain number of votes?  implementations?  number
of bugs?  days without incident?

Unfortunately, most of the discussions are emotional at this point -
rehashing like or dislike of the same features over and over.  In the end,
I don't see an objective way to resolve subjective classifications of
readiness - is there a good objective metric?

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 07:34:56 +0000

In message <CABaLYCsF_UTjxVwKbOJwW=[email-masked]>, Mike Belshe writes:

>I actually did wrack my

I'd say that the sheer number of unmistakeable pronouncements about
deliberately reduced functionality implementations is a good metric.

We have two (or more ?) major-ish browsers nixing HTTP/1 upgrade.

We have a number of proxies (involved in about 30-50% of all HTTP1
content delivery) nixing CONTINUATION and we have a lot of webmasters
who have yet to see any evidence that adding HTTP/2 support would
ever be worth their while.

And we have talk about HTTP/3.0 before HTTP/2.0 even got to Last Rites.

Maybe the mistake was to rename SPDY ?

If this draft had been named SPDY and with a stated goal of "giving
a better user experience" at a subset of large web-properties at
the expense of interoperability with HTTP/1, then it would be a
very fine draft indeed, because most people could just ignore it and
firewalls and content-filters could just block it and force
fall-back to HTTP/1.0.

But naming it HTTP/2.0 rightfully raises the expectations a LOT,
and the talk about HTTP/3 already now makes it painfully obvious
that those expectations are not even close to being been met.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 2 Jul 2014 11:03:41 +0200

Le Mar 1 juillet 2014 08:30, William Chan (陈智昌) a écrit :
> Try not to be too combative here :) I specifically caveated CONTINUATION
> with an "If we think servers need to at least be able to support reading
> continuation frames." In this thread, I'm not trying to debate the
> controversial stuff. I'm just trying to get a list of the stuff we have a
> relatively strong consensus around and how we keep those usable.

Well speaking as an intermediary operator here, your list of "healthy"
things to do just about convinced me http2 is going to be a major mess
with some actors gaming the system just because they can, and I'd be
better off blacklisting it wholesale rather than pay people to understand
the security implications of those games.

Security is expensive
Complexity is expensive
Most of us do not have Google's budget to play with those
When your Internet flows have more operational consequences for your
employer than a skipping youtube video you do not play those games.

http1s MITM looks better from an operational POW every day.

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 2 Jul 2014 11:23:38 +0200

Le Mar 1 juillet 2014 08:55, Mark Nottingham a écrit :
Mark,

> to derail other discussions isn't appropriate.

In the defence of PHK he seems to be the only one defending the http users
at large and not the subset present here

> Also, emotive language like "bogus misfeatures" and "blackmail" doesn't
> help make decisions; it's just a distraction. Please refrain.

Because
> In order to prevent the extension mechanism from failing (due to
> other sort of brokenness)

is not emotive and a distraction?

Do you not understand still that websocket and other attempts to force
some classes of traffic through security equipments didn't fail because of
some technical default in those equipments, but because those equipments
were deployed to block those classes of traffic in the first place? And
that any attempt to force the issue in http2 will result in the same
outcome for this new protocol?

And BTW, in what way PHK's characterisation of
> A vendor that owned both an auto-updating client and popular website
> could enforce this.

is not perfectly accurate?

Regards,

-- 
Nicolas Mailhot

---

From: "Eric J. Bowman" <[email-masked]>
Date: Wed, 2 Jul 2014 03:42:50 -0600

> ever be worth their while.

+1

> And we have talk about HTTP/3.0 before HTTP/2.0 even got to Last

+1, I wouldn't be re-participating here if it weren't for the "we'll
get it right in HTTP/3" mantra, a major indicator of problems with
HTTP/2 in general, leading me to some of the same specifics PHK
mentions.

I'd make technical arguments (which I'm certainly capable of if I
thought it worthwhile) if I believed the issues with this protocol
were being resolved based on what's best for the Web. Which I don't,
leading me to frowned-upon political discussion about motives.

> that those expectations are not even close to being been met.

+1

-Eric

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 2 Jul 2014 11:53:19 +0200

Le Mar 1 juillet 2014 23:08, William Chan (陈智昌) a écrit :

> intermediary interference.

Well you were told last year that http2 needed a good intermediary story
or intermediary people would get things into their own hands. And that
they could make your life miserable just as you could make theirs
miserable. And that the "bad" intermediary people where financed by "good"
intermediary users because "good" intermediaries have been made to suck so
much people had no choice but to junk "good" intermediaries in favour of
"bad" working ones.

I don't see how your solution/proposal to make intermediaries suck even
more by guerilla fighting all of them indiscriminately in http2
implementations is not going to result in more of the same.

Make standard malware-scanning youtube-blocking-at-work intermediary work
and most of the market for MITM proxies that plan to do deep inspection
will evaporate.

-- 
Nicolas Mailhot

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 03:14:22 -0700

On Wed, Jul 2, 2014 at 12:34 AM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CABaLYCsF_UTjxVwKbOJwW=
> [email-masked]>, Mike Belshe writes:
>
> >I actually did wrack my

protocol upgrade has always been optional at the client discretion.  this
is not new with http/2.

> ever be worth their while.
 continuation is not a "throw the whole thing out" issue.

> And we have talk about HTTP/3.0 before HTTP/2.0 even got to Last Rites.

Well, this is circular.  I believe you were the person that started the
http/3 talk, because you didn't like http/2 from the beginning.

So now you're saying we should nix http/2, because you started talking
about http/3.

Mike

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jul 2014 20:26:25 +1000

> at large and not the subset present here

Sorry, nobody gets to wear the mantle of “I defend the users." That’s too easy.

> is not emotive and a distraction?

Um, yeah.

> outcome for this new protocol?

I understand that. 

These arguments are perfectly valid, and indeed may carry the day (in this case particularly, since I can’t see there being any normative outcome agreed upon).

What I’m not willing to tolerate is the continuing degradation of the discussion into point-scoring, personal attacks and assumptions of ill intent by one’s opposition. It has no place here. For example, you didn’t need to start that paragraph with “Do you not understand…” That’s needlessly aggressive; just make the argument without impugning my ability to understand it.

BTW, the above is not a particular comment on PHK’s participation, BTW — it’s about what seems to be a growing trend in the discussion.

> is not perfectly accurate?

Yep.

Thanks,

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 2 Jul 2014 20:26:24 +1000

MUST RESIST URGE TO JOIN CONTINUATION DISCUSSION....

> client and popular website could enforce this.

I think that h2 is going to have an issue with extensions.   Because it has
been a deliberate design decision to conflate the framing layer with
application layer semantics, then it is simply not possible to expect any
extension to pass along a path that does not fully understand the
extension.    If you can't understand the framing without understanding the
protocol semantics, then intermediaries are not going to be able to forward
extensions that they do not understand.

So this can go several ways - either:

a) h2 goes out without any extensions.  Intermediaries will then be
implemented and deployed that have the HTTP semantics hard baked into the
framing layer, so that any future extensions will fail to deploy widely.
We will then see things such as websocket end up being send over perverted
HTTP streams rather than in dedicated streams.

OR

b) h2 will be deployed together with several extensions: websocket, frame
compression, large frames, large headers etc.  h2 Intermediaries will then
be developed with knowledge that extensions can and do exist, thus
hopefully limiting the deployment of intermediaries with hard baked HTTP
only support.  In such an eco system it might be possible to come up with
extensions that have non HTTP stream semantics and may succeed to get
deployed.    However it still creates a significant hurdle for them to
achieve some market presence so that the majority of intermediaries will
have extension plugins available, so I suspect that an initial batch of
extensions will get supported, after which time it will become impossible
to develop new ones and new ideas will need to pervert one of the existing
extensions to get through the h2 web.

OR

c) This WG will realise the error of conflating framing with application
layer semantics and the protocol is significantly rewritten.
Intermediaries can then be written that can work entirely at the
framing/stream level with little or no knowledge of the semantics of the
streams they are forwarding.  In such an environment, extensions for thing
like websocket can be written without the need for all intermediaries to
know of the extension.

I doubt c) going to happen, I fear that a) will, but hopefully Wills thread
will encourage the development of extensions in parallel so that b) might
happen.

> should make sure to exercise this code path some part of the time.

OK I could not resist!   Seriously are you suggestion that clients
deliberately use continuations even when not necessary to take away the
option of servers/intermediaries to not implement a feature that is needed
only for very large headers?

I think something like
http://autobahn.ws/testsuite/reports/servers/index.html should be
sufficient to identify which clients/servers support which features.

regards

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 10:37:29 +0000

>protocol upgrade has always been optional at the client discretion.  this

Absolutely, just like my decision to implement HTTP/2 or not
implement HTTP/2 is entirely discretionary.

But such discretionary decisions people will make really big
footprints on the future success of HTTP/2 in the wider web,
so these "political statements" should weigh heavy in the
judgement of the drafts future prospects.

Of course if the only thing cares about are a few $BigWWW sites,
then that doesn't matter, but if the question is if HTTP/2.0 is
worthy of its name, it matters a LOT.

> continuation is not a "throw the whole thing out" issue.

Actually it is.

It's a clear indication of technical ineptitude when it comes to
good and clean protocol design.  I'm 100% certain that you'd get
flunked by Andy Tanembaum for a END_STREAM flag which doesn't, and
if that doesn't do it, a framesize with a maximum payload of (2^n-1)
certainly will.

>So now you're saying we should nix http/2, because you started talking

I'm saying that if we rush into Last Call with the draft we have
now, we have no choice but to start talking about HTTP/3 right away,
because it is simply not good enough.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 04:01:21 -0700

On Wed, Jul 2, 2014 at 3:37 AM, Poul-Henning Kamp <[email-masked]>
wrote:

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

Your argument is full of name calling (political/bigwww) and nothing more.

> if that doesn't do it, a framesize with a maximum payload of (2^n-1)

As usual, you're relying on name calling to amplify an otherwise minor
point.

Some of these features are artifacts of the standardization process which
wouldn't be my first choice either.  But they are good enough.

> because it is simply not good enough.
It is a misrepresentation to call HTTP/2 "rushed".   To the contrary, I
HTTP/2 may have more implementation experience from a more diverse set of
implementors than pretty much any protocol in the history of the IETF.  I
can't be certain of this claim, but it is undeniable that we have a lot
more experience with this protocol than most being standardized.  On the
time metric, we've now been working on it for over 2 years.  It's not
rushed at all.

I realize you disagree with the items you enumerated.  But lets not call
them 'rushed' just because you don't like them; its not rushed.

mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 11:24:51 +0000

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

>What I'm not willing to tolerate is the continuing degradation of the 
>discussion into point-scoring, personal attacks and assumptions of ill 
>intent by one's opposition. It has no place here.

I think we're coming up to a point where peoples capacity for
understanding the oppositions arguments may be impaired by who pays
their salary.

I am deeply sympathetic to both the original SPDY rationale and the
"TLS everywhere" battle-cry, if nothing else because of the fundamental
truth of the "end-to-end" argument.

But I think it is naiive and ill-adviced to think that our protocol
can sneak basic human rights in through the backdoor, against the
will, intent and duly enacted laws that say otherwise from legislatures
all over the world.

That can and will only lead to an armsrace, where our own tax
payments are used against our goals.

The $BIGWWW "political" agenda against MITM has shaped HTTP/2.0 to
be almost hostile to any kind of proxy, despite the fact that almost
everybody uses proxies to deliver their web content.

For instance the $BIGWWW focus on running over TLS means that other
high-performance applications, such as News, TV and porn gets
saddled with a small and horribly inefficient (2^n-1, really ?)
framesize.

I'm fully behind fighting MITM, but handicapping the protocol to
do so is like going to battle but refusing to get heathen blood
on your sword...

We should deliver tools, not policies.

Poul-Henning

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Jul 2014 21:29:05 +1000

> saddled with a small and horribly inefficient (2^n-1, really ?)

Making smaller, more targeted proposals might help; e.g., a well-aligned but still small frame size.

Unfortunately, you’ve left it until very late to get involved in detail, which makes getting such changes in more and more difficult.

> on your sword…

You had me until you started talking about blood...

> We should deliver tools, not policies.

Agreed - except so much as the tools encourage or accommodate policies that may not be fully understood (but that’s a different discussion).

Regards,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 11:30:53 +0000

>layer semantics and the protocol is significantly rewritten.

Isn't that called SCTP ?

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 2 Jul 2014 21:36:27 +1000

On 2 July 2014 21:30, Poul-Henning Kamp <[email-masked]> wrote:

> In message <CAH_y2NHdOt0nmxZkXcoHyWrv-Map7cCqJh=
> [email-masked]>, Greg Wilkins writes:
>

Indeed.  And the inability to actually deploy SCTP in a world with hard
baked support for TCP should serve as a lesson against hard baking support
for HTTP into the h2 framing.

cheers

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 11:47:58 +0000

>but still small frame size.

I did.

It was called jumbo frames.

It got shot down.

You just did so again a minute ago in another email.

>Unfortunately, you've left it until very late to get involved in 
>detail, which makes getting such changes in more and more difficult.

Come of it Mark...

You know perfectly well that I already from the start objected to the
accelerated timeframe, because it only left room to gold-plate SPDY
with all its warts.

Some of us tried to squeeze out a competing draft nontheless, only to
be steam-rolled with the "no time for that..." argument and none of
the points made in that draft ever revisited systematically and whenever
we raise them, they get shut down.

Given the appearance of a pre-ordained result and no willingness
to even accept the legitimate concerns of proxy implementors, I had
better things to do.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 04:56:01 -0700

> for HTTP into the h2 framing.

No no no  - we absolutely *did* learn the SCTP lesson.  We intentionally
yet begrudgingly incorporated some of the features out of the transport
(multiplexed streams) because we learned from SCTP that it couldn't
effectively be done at the transport layer. We learned that transport
protocols had an upgrade problem, but application protocols did not.

So we should all feel great about this - multiplexed streams were trapped
for over a decade inside SCTP, and h2 is finally unlocking it for http.
 This is a huge learn-from-history victory.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 12:12:27 +0000

In message <CABaLYCs4a=[email-masked]>
, Mike Belshe writes:

>We learned that transport

So why is FF and Chromium not supporting Upgrade: ?

> This is a huge learn-from-history victory.

That is very much a matter of perspective.

Taking the fight and using HTTP to push SCTP adoption, would have given
us so much more than than the current drafts erzats-framing does.

Anycast for instance.

---

From: Peter Ghosh <[email-masked]>
Date: Wed, 2 Jul 2014 08:29:57 -0400

Help

On Wednesday, July 2, 2014, Poul-Henning Kamp <[email-masked]> wrote:

> In message <CABaLYCs4a=
> [email-masked] <javascript:;>>
> , Mike Belshe writes:
>

-- 
=================
Peter Ghosh
267.471.2451 Mobile
[email-masked]

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 07:17:44 -0700

On Wed, Jul 2, 2014 at 5:12 AM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CABaLYCs4a=
> [email-masked]>
> , Mike Belshe writes:
>

This has all been hashed out before.

> us so much more than than the current drafts erzats-framing does.

Again, this has all been hashed out.  Read my presentations from 4 yrs ago
to learn why this would not have worked.  I don't have time to go back to
remedial basics with you over and over again.

mike

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 07:24:50 -0700

> we raise them, they get shut down.

You were not steam rolled.  You've been making the same arguments for 2
years.   You've been listened to.  Some of your suggestions have been
taken.  You've definitely been heard.  You just don't like the answer.

Mike

---

From: Mike Bishop <[email-masked]>
Date: Wed, 2 Jul 2014 16:23:37 +0000

Presumably nothing -- the 502 carries END_STREAM, so the server is (at least) half-closed from the server side.  The connection is still valid, because HPACK processed all the input, it just stopped emitting anything.

-----Original Message-----
From: Willy Tarreau [mailto:[email-masked]] 
Sent: Tuesday, July 1, 2014 2:10 PM
To: Jeff Pinner
Cc: Johnny Graettinger; William Chan (?????????); Jason Greene; HTTP Working Group
Subject: Re: Encouraging a healthy HTTP/2 ecosystem

On Tue, Jul 01, 2014 at 02:04:16PM -0700, Jeff Pinner wrote:
> > In 1.1 it would return 502 bad gateway. In 2.0, assuming I manage to 
> > implement it to the server, I don't expect it to be able to 
> > multiplex multiple streams over a single connection before we've 
> > finished HTTP/3. I'm serious. 2.0 is a major architecture change for 
> > low-level intermediaries. So I'd say that for now, with the elements 
> > I have, a protocol error on 2.0 will be handled the same way as in 
> > 1.1 : the connection will be torn down and the effects will be exactly the same : only the request using that connection will be impacted.
> 
> What we do:
> 

But what do you do then with the server connection and/or stream when you send the 502 to the client ?

Willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 2 Jul 2014 12:19:19 -0700

On Tue, Jul 1, 2014 at 4:07 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <CAA4WUYjHU__T9TT868mory=szszgXH3SCbod+F7=
> [email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF

I'm confused. I don't understand why you think this is a bad analogy. What
information can a HTTP/2 extension carry that a TCP option can't?

> There are never any easy techical fixes for hard political problems.

Great. I think we're making progress here on the core discussion. Yes, I
think we agree that the current state of things is that many ports are
unusable due to filtering proxies and the like. Therefore, more and more
protocols are getting tunneled over port 80 and port 443, and they're
moving up the stack. We're doing multiplexing in the application layer
since we've been unable to deploy multiplexing at a lower layer. It sounds
to me like you think that the inability to deploy new TCP options is
somewhat unfortunate, but it's the best reality we can hope for because
"There are never any easy technical fixes for hard political problems."

My assertion is that this situation is unacceptable. You're right, for
political / compliance reasons, proxies are going to be there and do these
things that ossify our protocols and force us to tunnel higher up the stack
and develop way more cruft in our protocol stack. I do think that we should
fight this. If MITM proxies outright drop ALPN from the negotiation,
thereby disabling HTTP/2, then so be it. I think it's better to let those
networks fall behind the rest of the internet than force the vast majority
of the internet into the lowest common denominator. I'd rather pick this
battleground here and now, rather than continuing to tunnel more complexity
higher up the stack every time we want to deploy new changes without having
to update all intermediaries on the internet.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 19:48:53 +0000

In message <[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF

>information can a HTTP/2 extension carry that a TCP option can't?

Pretty much any kind of contraband a filtering proxy might be
installed to stop ?

(Further: Very few people are able to add a new TCP option to their
outgoing packets.  Everybody can add a new HTTP/2 extension simply
by downloading a program, but yes, I do know about the IP-over-TCP-OPTIONS
hack, and it is very relevant to this discussion.)

>We're doing multiplexing in the application layer
>since we've been unable to deploy multiplexing at a lower layer.

We have never really tried to deploy multiplexing in the transport
layer, we know it isn't happening on its own, but we have never
really tried to push it.

If we can (and that's TBD of course) publish a HTTP/n running over
SCTP which gives tangible benefits, then people would have a reason
to make SCTP work.

Without a killer-app, it stays on their TODO list.

Right after IPv6.

And giving up without ever even trying is a looser-attitude IMO.

>It sounds to me like you think [...]

I think that always taking the easy path through whatever unintended
wormholes we may be able to find is going to totally muck up any
semblance of architecture which the internet protocols ever had.

It is also a cowardly abdication as members of society, for our
and our technologys impact on the lay person and their civil rights.

If there were good (as opposed to merely "meh...") reasons for
making TCP options, IPv6 or SCTP work, they will start working all
by themselves, but you have to dangle at tasty carrot for it to
happen.

>"There are never any easy technical fixes for hard political problems."

I'm not talking about TCP options, I'm talking about freedom of
speech.  Privacy.  Protection against unreasonable search, seisure
or monitoring.

Also known as "the hard political problems".

>and develop way more cruft in our protocol stack.

And I'm telling you:  That is neither a way to build a civilized society nor
a well-functioning or -performing network.

The Global War on Privacy, as carried out by governments and gigacorps alike
can only be won through politics, technology will never do it, and doing
"elastic advances" further and further up the stack is just an eupherism
for slow defeat.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 2 Jul 2014 13:03:43 -0700

On Wed, Jul 2, 2014 at 12:48 PM, Poul-Henning Kamp <[email-masked]>
wrote:

> In message <
> [email-masked]>,

I don't understand this statement. A TCP option can carry the same
"contraband", right?

> hack, and it is very relevant to this discussion.)

I think this is the critical distinction. You are more concerned about
extensibility within a protocol that is typically implemented in user space
(HTTP/2), as opposed to a protocol that is typically implemented in kernel
space (TCP). Is that it? If so, I think that's a reasonable distinction to
highlight.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 20:35:50 +0000

In message <CAA4WUYhKLVyzPhOG2oQUiL0gJn0Zzye=[email-masked]>, =?UTF-8?B?V2lsbGlhbSBDaGF

>space (TCP). Is that it? If so, I think that's a reasonable distinction to

Yes, it is a critical distinction.

The reason IP-over-TCP-OPTIONS still mostly works, is that it is
so hard to deploy and use that it has not become a big enough
problem, just like almost no companies have RFC1194 filters in place.

Being able to download a "unfiltering" version of a browser which
tunnels contraband through port 80 or 443 will be met with an
entirely different kind of resistance.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 2 Jul 2014 13:46:02 -0700

> layer, we know it isn't happening on its own, but we have never

Actually this is not true.  While at Google, way back when we were doing
SPDY research, we worked with the Univ of Maryland team which was doing
exactly this.  (I was the sponsot from Google that helped them attain a
research grant to help with their work)  This was the same team that put
together the RFC for how to run HTTP/1.1 over SCTP.  You're welcome to
reach out to Paul Amer, the research professor we worked with who led the
team there and get more information yourself, although facts don't seem to
be what you're generally interested in.

We would have loved for SCTP to be an answer rather than moving up the
stack, it was not practical for several reasons:
   a) no machines have SCTP stacks on them today (not windows, linux, macos
or any major mobile OS)
   b) there are two leading SCTP stack implementations, but neither has
received a ton of attention and there are a lot of bugs (simple stuff in
the handshakes even).
   c) it didn't really work that well anyway.  If you look at how multiple
streams are negotiated in sctp, you'll see its all pre-setup in an odd way.
 it can be made to 'work', but its not very good.  So given the challenges
of a & b, its actually not a good starting point.

Anyway, I'm sure you'll have a thousand reasons why this was inadequate and
doesn't count as "really trying", and I'm sure the great PHK could have
done a better job with just 3 hours of his mega brain on the problem than
the team of grad students did over the course of several years...  but
hey,I didn't know you then.

> SCTP which gives tangible benefits, then people would have a reason

I 100% support your doing research on this and coming back to the group
when you're done!

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 02 Jul 2014 20:53:18 +0000

In message <CABaLYCvsmh=pqg3Sng72vvKbXTCbHt_mtDE-wtVRz9yiCbs=[email-masked]>, Mike Belshe writes:

I've only heard the SCTP story through the people who worked on it
in FreeBSD, and their verdict was simply "lack of interest" because
people would rather squeeze through some random loophole, than
attempt to architecture.

As for SCTP being the right or wrong basis I have no opinion.

---

From: Roland Zink <[email-masked]>
Date: Thu, 03 Jul 2014 01:25:08 +0200

On 02.07.2014 21:19, William Chan (陈智昌) wrote:
>
> Great. I think we're making progress here on the core discussion. Yes, 
> I think we agree that the current state of things is that many ports 
> are unusable due to filtering proxies and the like. Therefore, more 
> and more protocols are getting tunneled over port 80 and port 443, and 
> they're moving up the stack. We're doing multiplexing in the 
> application layer since we've been unable to deploy multiplexing at a 
> lower layer. It sounds to me like you think that the inability to 
> deploy new TCP options is somewhat unfortunate, but it's the best 
> reality we can hope for because "There are never any easy technical 
> fixes for hard political problems."
Multiplexing is a good idea but doesn't solve all problems. For example 
WTP (part of the WAP protocol stack) had multiplexing but was dropped in 
favor of HTTP/1.1.
> political / compliance reasons, proxies are going to be there and do 
> these things that ossify our protocols and force us to tunnel higher 
> up the stack and develop way more cruft in our protocol stack. I do 
> think that we should fight this. If MITM proxies outright drop ALPN 
> from the negotiation, thereby disabling HTTP/2, then so be it. I think 
> it's better to let those networks fall behind the rest of the internet 
> than force the vast majority of the internet into the
Dropping ALPN could be difficult, so the result may be that the network 
gets disconnected or the MITM proxy will do HTTP/2. If we loose to many 
networks then HTTP/2 will go nowhere. What to do if something like this 
is build into most home routers to protect the kids?
> lowest common denominator. I'd rather pick this battleground here and 
> now, rather than continuing to tunnel more complexity higher up the 
> stack every time we want to deploy new changes without having to 
> update all intermediaries on the internet.
The internet nodes need to support your changes. If you change how 
things are routed, for example by saying the only allowed intermediaries 
are the ones that are controlled by you so you can update them, then 
this becomes a different network and is probably no longer the Internet.

Regards,
Roland

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Jul 2014 08:22:06 +0300

It’s somewhat of a chicken-and-egg thing, but in addition to Mike’s (a), (b), and (c), there’s also (d) firewalls have poor support for SCTP.

As an example, our firewall can recognize SCTP packets, and even mark SCTP “connections” (we call everything a “connection”, even if it’s UDP. The proper term should probably be “flows”), but the kind of rules you can configure are “this IP can/cannot do SCTP to this IP”. That’s like the TCP firewall we had in ’93, except it doesn’t even protect from network attacks. 

If HTTP-over-SCTP became a thing people use, we could write the support, we could add all of the HTTP inspection for malware and bot traffic and data leakage and unacceptable content and such, but that would take time. In the meantime, administrators would rather block SCTP, forcing browsers to TCP rather than let any and all traffic through. Even when we do add that support, we’re not Google. Old versions of our product keep running for years after we release a new version. I’m told that our “R65” version from 2007 is still used a lot, even though it’s out of support. 

So “surfing from work” will take a long time to be not blocked. Also, CPE routers people have at home are very likely not to handle SCTP the way draft-ietf-behave-sctpnat recommends, so browsing from home isn’t going to work very well either. Why would anyone deploy a website over SCTP then?  And if nobody deploys websites, why would browser vendors add the support?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 03 Jul 2014 06:34:34 +0000

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

>Why would anyone deploy a website over SCTP then?

Because the carrot was big enough ?

If for instance HTTP/SCTP increased sales 10% in your webshop, that
would surely do it.  Not that I know how that would ever happen.

It should be borne in mind that there is a cost to even attempting:

Most of us are still carrying code around to handle HTTP/1.0 and that
code is seldom used and subject to code-rot and consequent security
issues.

More protocols -> more code -> more bugs -> more security holes.

In that light it was good that HTTP/SCTP never grew to any relevant
size:  It would be terrible to have to keep it around just for one
or two unescapable killer applications.

(Denmarks National identification system "NemID" is just now wiggling
out of the mandatory java-applet, ask any dane how much pain that
has been!)

Ideally our goal for any new HTTP version should have been to
outcompete all previous versions, with a simpler, faster and more
robust codebase, so that we ended up with less code and, fewer bugs
and better security in the long run.

But it is not obvious that will ever be possible: HTTP/1.1 became
a success for many good reasons.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 3 Jul 2014 16:49:44 +1000

> would surely do it.  Not that I know how that would ever happen.

Have a read of http://www.bookofspeed.com/chapter1.html  which talks about
studies that show that improving the speed of rendering does have a very
measurable effect on the return you can get from a site.

I think  h2's focus on performance is driven primarily by such studies that
show speed==revenue, and rightly so I think.

cheers

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 03 Jul 2014 07:45:46 +0000

>show speed==revenue, and rightly so I think.

Ohh absolutely, no disagrement there.

I just don't think anything done to HTTP can improve sales 10%, and
to roll out something as different as SCTP you would probably need
that scale of improvement to get the ball rolling.