Subject: Call for Adoption: HTTP/2 Bis

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2020 11:36:19 +1100

Based upon discussion at the interim and subsequent activity on the HTTP/2 issues list, the Chairs believe that the following is in-scope for a HTTP/2 bis effort:

* Incorporating errata
* Makeing strictly editorial improvements
* Aligning with the publication of http-core
* Incorporating RFC8740 to align with the publication of TLS 1.3
* Updating references to other specifications as necessary
* Documenting additional security considerations
* Providing implementer guidance where appropriate
* Addressing problems or ambiguities where the affect interoperability, so long as the solution does decrease interoperability
* Making the protocol more resistant to ossification, so long as doing so does not affect interoperability

This effort will not create a new version of HTTP; its output will not have a distinct ALPN identifier. As such, new features and backwards-incompatible changes like updates to the HPACK static table are out of scope. For the same reason, deprecating or removing Server Push and the Priority scheme is out of scope, although implementation advice might contextualise their use. 

Please indicate whether you support this approach to the work; the CfA will end in two weeks on 17 December.

Cheers,

--
Mark and Tommy

---

From: Ian Swett <[email-masked]>
Date: Wed, 2 Dec 2020 20:46:00 -0500

That seems sensible to me, but I'd like a better understanding of
whether we ever expect to be able to ship extensions to HTTP/2 or not
before I support the lack of a new ALPN.

Google servers have attempted to enable WebSockets over H2 twice to my
knowledge and had to roll it back both times(once only a few months
ago).  +Bence
Béky <[email-masked]> has done some work to improve the server-side
ecosystem via Chrome experiments, but I'm not sure if we expect enough
improvements in clients and servers to ship extensions in the near future.
If we don't mint a new ALPN, I believe we should call out that extensions
face deployment risk without a new ALPN.

A few IETF contributors I trust have put forth the idea that in 5 years, H2
will no longer be worth supporting given the widespread deployment of H3,
so possibly this is a self-solving problem?

Thanks, Ian

On Wed, Dec 2, 2020 at 7:40 PM Mark Nottingham <[email-masked]> wrote:

> Based upon discussion at the interim and subsequent activity on the HTTP/2
> issues list, the Chairs believe that the following is in-scope for a HTTP/2
> bis effort:
>
> * Incorporating errata
> * Addressing problems or ambiguities where the affect interoperability, so
> long as the solution does decrease interoperability
> This effort will not create a new version of HTTP; its output will not
> have a distinct ALPN identifier. As such, new features and
> backwards-incompatible changes like updates to the HPACK static table are
> out of scope. For the same reason, deprecating or removing Server Push and
> the Priority scheme is out of scope, although implementation advice might
> contextualise their use.
>

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2020 06:16:50 +0100

On Thu, Dec 03, 2020 at 11:36:19AM +1100, Mark Nottingham wrote:
> This effort will not create a new version of HTTP; its output will not have a
> distinct ALPN identifier. As such, new features and backwards-incompatible
> changes like updates to the HPACK static table are out of scope. For the same
> reason, deprecating or removing Server Push and the Priority scheme is out of
> scope, although implementation advice might contextualise their use. 

This also means it doesn't exclude what remains possible using SETTINGS,
which I think is the right approach for an already deployed protocol :-)

> end in two weeks on 17 December.

I support adoption.

Thanks!
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 3 Dec 2020 07:01:15 +0100

Hi Ian,

> before I support the lack of a new ALPN.

My personal feeling on this is that adding a new ALPN will not solve a
real issue but will introduce more interop issues. The problem is always
the same, no single stack implements 100% of the features of a protocol,
and by advertising sub-versions we imply that all of these features are
supported instead of making them discoverable or negotiable. For example,
plenty of hand-written clients advertising support for HTTP/1.1 did not
support chunking. And dealing with these only adds extra work on all
implementations. I think that the ALPN number should reflect what the
client can instantly trust to save a round trip without waiting for
settings, i.e. on-wire format, protocol elements (e.g HPACK), limits and
retryable defaults. I don't see how a new ALPN will help for websocket
because I'm fairly sure we'll find this new ALPN deployed by new
implementations to support the new protocol elements even if they don't
implement websocket or don't know where to forward it. In this essence,
the client will still have to be able to retry it a different way. So
really a new ALPN will not solve websocket interoperability issues.

> so possibly this is a self-solving problem?

I'm not that much convinced that H3 will have that much love in the
datacenter until it supports being transported over TCP, and for now H2
is much more capable than H1 for application-to-application exchanges.
What I suspect once H3 becomes popular is that we'll see attempts at
transporting it over TCP to replace H2 though. Will that take off ? I
cannot predict.

Cheers,
Willy

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 3 Dec 2020 08:00:09 +0100 (CET)

> end in two weeks on 17 December.

I support.

-- 

  / daniel.haxx.se

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 3 Dec 2020 10:00:33 +0100

What Willy said.

> Am 03.12.2020 um 07:01 schrieb Willy Tarreau <[email-masked]>:
> 
> Hi Ian,
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 4 Dec 2020 11:59:13 -0800

> On Dec 2, 2020, at 4:36 PM, Mark Nottingham <[email-masked]> wrote:
> 

I support doing the work to update the RFC, but I don't see any reason to
limit its scope as a chairs' mandate.

This is the HTTP WG. We should be working on HTTP enhancements.
We should not stop discussion of issues just because we don't
expect the HTTP/2 editor to write them into that specific draft.

Hence, I'd like this to be rephrased as:

There is work to be done on HTTP/2, here is what we know now, and that
will be done within *this* specific draft. Further additions will be subject to
WG consensus. Extensions, if any, may be discussed within other drafts.
Prior to WG last call, the WG will decide whether any such extensions
have progressed to the point of inclusion within HTTP/2.

Cheers,

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 4 Dec 2020 21:45:09 +0100

> have progressed to the point of inclusion within HTTP/2.

I like this. +1 :-)

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Dec 2020 10:42:51 +1100

Hi Roy,

> On 5 Dec 2020, at 6:59 am, Roy T. Fielding <[email-masked]> wrote:
> 

This isn't proposing a "chairs' mandate" (whatever that is).

We scope our larger pieces of work so that people know whether they want to participate, and to help surface disagreements and other areas to focus on early. We've done this pretty consistently through the lifetime of the WG, and it's been helpful in assuring that we have alignment about what we're working on and visibility in to where the issues are.

The scope is confirmed by consensus (here, in the meeting, on the repo, and now on the list), but we can revisit the scope if we have consensus to do so. I.e., consensus on a general scope here does not bind the WG if it gains consensus to exceed it in the future.

In other words, what the scope adds is some amount of friction against things that are outside it; not enough to overcome if there's need to, but enough to encourage focus on a common goal, so we're able to finish in a reasonable amount of time. That's valuable to those who participate in good faith (in particular, the editors).

I think I remember you bringing up a similar objection when we chartered HTTP/2 originally. I think our experience there was a good demonstration of this in practice; having a defined scope helped concentrate and align the efforts of the group, but we didn't see it as binding when we got to issues that hadn't been anticipated; we just needed to gain consensus on how to address them.

Of course, as you point out, we can still *discuss* things on the list (etc.) even if they're not in this particular draft; we're pretty accustomed to doing several things at once.

All of that said - if there's consensus in the group to adopt h2bis without any defined scope, we can do that too. How do folks feel about that?

Cheers,

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 5 Dec 2020 17:08:04 -0800

> On Dec 5, 2020, at 3:42 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Roy,
> 

"the Chairs believe that the following is in-scope"?

Scope defines a limitation on debate and on editors. Honestly, I'd rather
just let Martin decide what he wants to work on and anything else can
require WG consensus via github PRs for additions.

> In other words, what the scope adds is some amount of friction against things that are outside it; not enough to overcome if there's need to, but enough to encourage focus on a common goal, so we'r…

Scope means one thing, whereas how the chairs enforce that scope is another thing.

In that case, I do not agree with your belief that HTTP/2 bis ought
to be limited with regards to strictly editorial changes, ALPN version,
replacement or elimination of the priority scheme, deprecating server
push (and properly specifying the replacement), or updating the HPACK
table to be more efficient based on actual traffic analysis.

I don't expect the editors to do that work. I want other people to feel that
they wouldn't be wasting their time if they did the research and described
it as a separate draft. WG consensus would be required to merge such
change proposals.

And if the editors finish an update before any such proposals have reached
consensus, then we go ahead and submit a bis with nothing but editorial
changes and don't worry about it til the next bis (if any).

> I think I remember you bringing up a similar objection when we chartered HTTP/2 originally. I think our experience there was a good demonstration of this in practice; having a defined scope helped…

I thought the process was biased on a particular design and then failed
to deal with late technical questions about that design because too much
water under the bridge. I note those same technical questions are still
being called out of scope above. When are they going to be addressed?

> All of that said - if there's consensus in the group to adopt h2bis without any defined scope, we can do that too. How do folks feel about that?

+1 on adopting h2bis with or without a scope. I think h2bis is necessary regardless.

....Roy

---

From: Cory Benfield <[email-masked]>
Date: Tue, 8 Dec 2020 08:54:22 +0000

On Thu, 3 Dec 2020 at 01:49, Ian Swett <[email-masked]> wrote:
>
> That seems sensible to me, but I'd like a better understanding of whether we ever expect to be able to ship extensions to HTTP/2 or not before I support the lack of a new ALPN.
>
> Google servers have attempted to enable WebSockets over H2 twice to my knowledge and had to roll it back both times(once only a few months ago).  +Bence Béky has done some work to improve the server-side ecosystem via Chrome experiments, but I'm not sure if we expect enough improvements in clients and servers to ship extensions in the near future.  If we don't mint a new ALPN, I believe we should call out that extensions face deployment risk without a new ALPN.

It would be very good to characterise why we believe a new ALPN
doesn't just punt the ossification risk to the new ALPN. The only way
I see that happening is if we mandate GREASE as part of the new ALPN.
I'm open to extending the work to add that, but otherwise it seems
like we just end up defining a new zero-point and have to do this
again in five years.

> A few IETF contributors I trust have put forth the idea that in 5 years, H2 will no longer be worth supporting given the widespread deployment of H3, so possibly this is a self-solving problem?

I am with Willy: QUIC has yet to prove its worth in the DC setting.
This may be self-solving, but if it isn't it would be good for the WG
to have an idea of how we'd tackle it.

>> Please indicate whether you support this approach to the work; the CfA will end in two weeks on 17 December.

I support this approach.

---

From: David Benjamin <[email-masked]>
Date: Tue, 8 Dec 2020 11:14:57 -0500

On Tue, Dec 8, 2020 at 3:55 AM Cory Benfield <[email-masked]> wrote:

> knowledge and had to roll it back both times(once only a few months ago).
> +Bence Béky has done some work to improve the server-side ecosystem via
> Chrome experiments, but I'm not sure if we expect enough improvements in
> clients and servers to ship extensions in the near future.  If we don't
> mint a new ALPN, I believe we should call out that extensions face
> deployment risk without a new ALPN.
>

Even without GREASE, a new ALPN resets the slate. That means the old
versions of the various broken servers aren't included. The old culprits
have since fixed the broken implementations and will presumably not make
the same mistake. Especially if we actually manage to deploy HTTP/2
extensions this time, that'll also provide a hint to anyone that missed the
memo.

But, yes, whenever we reset the slate, we certainly should take the
opportunity to implement GREASE to help keep it there.

> > A few IETF contributors I trust have put forth the idea that in 5 years,
> H2 will no longer be worth supporting given the widespread deployment of
> H3, so possibly this is a self-solving problem?
>
> >> Based upon discussion at the interim and subsequent activity on the
> HTTP/2 issues list, the Chairs believe that the following is in-scope for a
> HTTP/2 bis effort:
> >>
> >> * Incorporating errata
> >> * Addressing problems or ambiguities where the affect interoperability,
> so long as the solution does decrease interoperability

---

From: Ian Swett <[email-masked]>
Date: Tue, 8 Dec 2020 13:05:11 -0500

> opportunity to implement GREASE to help keep it there.

+1 to David on GREASE.

>
>
>> > A few IETF contributors I trust have put forth the idea that in 5
>> years, H2 will no longer be worth supporting given the widespread
>> deployment of H3, so possibly this is a self-solving problem?
>>
>> >> * Addressing problems or ambiguities where the affect
>> interoperability, so long as the solution does decrease interoperability

---

From: Mike Bishop <[email-masked]>
Date: Thu, 10 Dec 2020 22:05:22 +0000

And to me, that’s the real question over a new ALPN.  If we can keep the token “h2” and add GREASE successfully, let’s do that.  If we can’t add GREASE without changing the ALPN token, we should consider changing the ALPN token.  Of course, that means we’re effectively minting “h2.1” or “h2-nobugs”, at which point we need not necessarily be limited to non-breaking changes.

To Roy’s comments, I’m comfortable with the distinction that the document being adopted now has a particular scope, and future documents that do other things may be considered for adoption in the future.  While water under the bridge is and was a poor argument for pre-standard working group drafts, it’s a very solid argument for a non-breaking revision of a deployed protocol.

I support adoption of the document, but I feel like aspects of the scope aren’t as settled as this announcement suggests.

From: Ian Swett <[email-masked]> 
Sent: Tuesday, December 8, 2020 1:05 PM
To: David Benjamin <[email-masked]>
Cc: Cory Benfield <[email-masked]>; Mark Nottingham <[email-masked]>; Bence Béky <[email-masked]>; HTTP Working Group <[email-masked]>; Tommy Pauly <[email-masked]>
Subject: Re: Call for Adoption: HTTP/2 Bis

On Tue, Dec 8, 2020 at 11:15 AM David Benjamin <[email-masked] <mailto:[email-masked]> > wrote:

On Tue, Dec 8, 2020 at 3:55 AM Cory Benfield <[email-masked] <mailto:[email-masked]> > wrote:

Even without GREASE, a new ALPN resets the slate. That means the old versions of the various broken servers aren't included. The old culprits have since fixed the broken implementations and will presumably not make the same mistake. Especially if we actually manage to deploy HTTP/2 extensions this time, that'll also provide a hint to anyone that missed the memo.

But, yes, whenever we reset the slate, we certainly should take the opportunity to implement GREASE to help keep it there.

+1 to David on GREASE.

>
> Thanks, Ian
>
> On Wed, Dec 2, 2020 at 7:40 PM Mark Nottingham <[email-masked] <mailto:[email-masked]> > wrote:
>>

I support this approach.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 11 Dec 2020 11:18:09 +1100

Hey Mike,

I agree that the discussion on grease needs to play out, and I can see a future where we come to consensus that a new ALPN identifier is useful in serving that goal. However, I don't think it's useful to talk about other breaking changes before that consensus (if it happens), based on the lack of interest in them in the discussion so far. Also, if we do gain that consensus, it would be good to have an agreement about whether other breaking changes are suddenly back on the table.

Does that make sense, and if so, can we modify the scope to capture it (with a direction on the latter question)?

Cheers,

> On 11 Dec 2020, at 9:05 am, Mike Bishop <[email-masked]> wrote:
> 
> On Tue, Dec 8, 2020 at 11:15 AM David Benjamin <[email-masked]> wrote:

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 11 Dec 2020 05:41:02 +0100

Hi Mike,

On Thu, Dec 10, 2020 at 10:05:22PM +0000, Mike Bishop wrote:
> And to me, that's the real question over a new ALPN.  If we can keep the
> token "h2" and add GREASE successfully, let's do that.  If we can't add
> GREASE without changing the ALPN token, we should consider changing the ALPN
> token.

But why would GREASE require a new ALPN ? Bence is already doing some
greasing and managed to find bugs in several of our implementations. I'd
rather push stronger in this direction after some code points can be
reserved for various purposes.

>  Of course, that means we're effectively minting "h2.1" or
> "h2-nobugs", at which point we need not necessarily be limited to
> non-breaking changes.

What I hate with changing ALPN is that it's a user-visible change. Asking
users to change their ALPN string from "h2,http/1.1" to "h2.1,h2,http/1.1"
just because a working group decided to slightly change the protocol for
the sake of better interoperability is hard to justify, especially after
it was claimed that the protocol is called "HTTP/2" because it will not
have a sub-version.

If we'd change the ALPN we should then think about all the on-wire changes
that were discussed in the past, like the poor hpack encoding, changing
initial settings etc. It doesn't seem worth doing with H3 knocking at the
door in my opinion.

Cheers,
Willy

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 11 Dec 2020 09:48:35 +0100

> Am 11.12.2020 um 05:41 schrieb Willy Tarreau <[email-masked]>:
> 
> Hi Mike,
> 

+1

> it was claimed that the protocol is called "HTTP/2" because it will not

As a revised h2 would need to be h4, this seems like a silly way to go. I am doubtful that fixing the situation of broken implementations by new protocol versions can be applied very often.

I think servers would rather publish special resources to make capabilities known. A client could check the resource /.well-known/h2/capabilities, for example. Not everything is page load time sensitive.

> initial settings etc. It doesn't seem worth doing with H3 knocking at the

I was only half-joking when I said it would be "h4".

> Willy

Cheers, Stefan

---

From: Bence Béky <[email-masked]>
Date: Fri, 11 Dec 2020 14:36:58 -0500

Hi,

I also support adoption of this document.

As Willy mentioned, doing GREASE with Chrome has somewhat promising
results.  I'm not aware of any sites that have problems with reserved
setting identifiers.  There are a number of sites that have issues with
reserved frame types, most notably https://slack.com.  However, all three
server bugs I'm aware of causing GREASE intolerance have been fixed, so
moving the ecosystem forward is a matter of upgrading (which I acknowledge
can be quite complex).  Also, it is a lucky coincidence that the particular
issue affecting slack.com only affects frame types above 0x20, and
PRIORITY_UPDATE frame type is 0x10, so that should not be an issue for the
time being.

There is also a GREASE intolerant middlebox product out there, and while
that bug has been fixed in recent releases, some older branches are still
supported.  In fact no available upgrade includes the fix for certain
hardware platforms.  See https://crbug.com/1127569#c9 for specifics.  I do
not know if this bug is triggered by frame type 0x10, or only larger values.

I guess these server bugs will be around for a little while, but not
forever.

I'm planning to implement PRIORITY_UPDATE in Chrome by the next release,
and based on what we've seen from GREASE, we might indeed run into issues
with sending the new frame and the SETTINGS_DEPRECATE_HTTP2_PRIORITIES
identifier, as Ian mentioned above.  The experiments so far happened only
on Chrome Dev and Canary channels, and an issue with a site as popular as
https://netflix.com has only been reported after two months, so it is still
possible that there is a bug with a website that is not popular enough that
I would have learned about it yet, but popular enough that it will block
PRIORITY_UPDATE launch.

Then there is the situation from the server's perspective.  An old version
of an HTTP/2 client library is intolerant to unknown setting identifiers:
it simply closes the connection if it receives any.  This causes
difficulties for WebSockets over HTTP/2 and also PRIORITY_UPDATE.  Also, I
am not aware of any GREASE experiments from the server side, so I do not
know what the situation is with reserved frame types.  I believe that
creating a new ALPN identifier would solve this particular issue: if these
two setting identifiers were sent by popular servers every time the new
protocol is negotiated, then clients would be forced not to close the
connection upon receiving them.  At the same time, I understand the
argument that a new ALPN identifier has huge costs.  We are currently
exploring other workarounds.

Cheers,

Bence

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 11 Dec 2020 20:57:43 +0100

Hi Bence,

On Fri, Dec 11, 2020 at 02:36:58PM -0500, Bence Béky wrote:
> issue affecting slack.com only affects frame types above 0x20,

This description exactly matches the bug you found that affected prior
haproxy versions, so possibly they're running on this and haven't applied
maintenance fixes (sounds scary though given that it would mean that
other much more serious issues wouldn't be fixed either). If that's it
we shouldn't even care with such issues as they are things of the past
given that software causing them have long been fixed.

> not know if this bug is triggered by frame type 0x10, or only larger values.

Similarly, by the time a new H2 spec is out, bogus versions will have
totally disappeared.

> I guess these server bugs will be around for a little while, but not

I have zero compassion for site operators which refuse to apply fixes.
I'm fine with slow processes requiring months of validation but not with
lazy or irresponsible admins not doing their most basic job. So I really
think we should not care a single second about deployments running on
older versions of software which was already fixed. In the worst case
these versions will disappear once a critical vulnerability appears in
their version or when the admin (ir)responsible for keeping it exposed
leaves the company. What should really matter to us is fundamental
incompatibilities caused by spec mis-interpretation. At this point it
looks like H2 doesn't suffer from such a problem at all.

> I would have learned about it yet, but popular enough that it will block

What I'm wondering is if we should plan a normalized method to report
implementation bugs to servers. We could for example have a .well-known
URL where a few information are sent (e.g. a link to the agent's bug
tracker). This way site owners could spot them in their logs when they
see many errors in their stats.

> know what the situation is with reserved frame types.

I doubt GREASE makes as much sense from infrastructure to clients. I mean,
there is incentive for fixing infrastructure components when millions of
clients face problems with a given site. But the other way around is much
different. There's a wide variety of clients around, some that users cannot
even update, and these ones will continue to occasionally fail without the
user having any effective power on them. This will only result in a bad
image for the sites triggerring the issues, for no perceived value for these
sites.

Just my two cents,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Dec 2020 15:44:24 +0100

Am 03.12.2020 um 01:36 schrieb Mark Nottingham:
> ...
> ...

+1

Best regards, Julian

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Dec 2020 21:16:01 +0000

These feed on each other.  Several of the proposed features require or might require a new ALPN.  That's an argument against them so long as we don't have to do a new ALPN otherwise.  If, however, we agree to do something that requires a new ALPN token then that argument against the others goes away and might change the balance of consensus.

That said, I agree with you that GREASE is the only maybe-requires feature that seems to have enough drive to push it over the edge regardless.  If we come to the point where a new ALPN is required, we could re-evaluate those other things.

-----Original Message-----
From: Mark Nottingham <[email-masked]> 
Sent: Thursday, December 10, 2020 7:18 PM
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; David Benjamin <[email-masked]>; Cory Benfield <[email-masked]>; Bence Béky <[email-masked]>; HTTP Working Group <[email-masked]>; Tommy Pauly <[email-masked]>
Subject: Re: Call for Adoption: HTTP/2 Bis

Hey Mike,

Cheers,

> Cc: Cory Benfield <[email-masked]>; Mark Nottingham 
> <[email-masked]>; Bence Béky <[email-masked]>; HTTP Working Group 
> <[email-masked]>; Tommy Pauly <[email-masked]>
> >> * Making the protocol more resistant to ossification, so long as 
> >> doing so does not affect interoperability
> >>

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Dec 2020 21:20:50 +0000

FWIW, I agree with you; I'd rather not mint a new ALPN.  It depends how
brutal we're willing to be with installed and not-upgraded systems.  An ALPN
change is high friction, but won't break them; simply deploying GREASE will
break some things that maybe deserve to get broken.

-----Original Message-----
From: Willy Tarreau <[email-masked]> 
Sent: Thursday, December 10, 2020 11:41 PM
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; David Benjamin <[email-masked]>;
Cory Benfield <[email-masked]>; Mark Nottingham <[email-masked]>; Bence
Béky <[email-masked]>; HTTP Working Group <[email-masked]>; Tommy Pauly
<[email-masked]>
Subject: Re: Call for Adoption: HTTP/2 Bis

Hi Mike,

On Thu, Dec 10, 2020 at 10:05:22PM +0000, Mike Bishop wrote:
> And to me, that's the real question over a new ALPN.  If we can keep 
> the token "h2" and add GREASE successfully, let's do that.  If we 
> can't add GREASE without changing the ALPN token, we should consider 
> changing the ALPN token.

What I hate with changing ALPN is that it's a user-visible change. Asking
users to change their ALPN string from "h2,http/1.1" to "h2.1,h2,http/1.1"
just because a working group decided to slightly change the protocol for the
sake of better interoperability is hard to justify, especially after it was
claimed that the protocol is called "HTTP/2" because it will not have a
sub-version.

Cheers,
Willy

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 17 Dec 2020 14:26:36 -0800

Hello all,

Thanks for all the feedback and discussion on the HTTP/2 Bis effort!

Based on the expressed support, we will be adopting this as a working group document. We’ll plan on starting out with the limited scope that’s been proposed (and was previously discussed on GitHub). Of course, the working group can later decide to expand this scope if necessary; any extended scope would be handled as a separate adoption call to go into this document.

Best,
Tommy

---

From: Ian Swett <[email-masked]>
Date: Sat, 19 Dec 2020 15:38:56 -0500

Thanks Tommy, one follow-up question.

If people attempt to deploy GREASE for HTTP/2 more widely and it's found to
be non-deployable, it seems like the second half of this bullet indicates
GREASE should be dropped, but that's not the conclusion I'm getting from
the above discussion.  Can you clarify that?

Making the protocol more resistant to ossification, so long as doing so
does not affect interoperability

A question for the working group is: Are there servers that are going to
actively pursue GREASE in H2?  We might do some, but it'll be limited in
scope due to past issues.

Ian

On Thu, Dec 17, 2020 at 5:28 PM Tommy Pauly <[email-masked]> wrote:

> Based on the expressed support, we will be adopting this as a working
> group document. We’ll plan on starting out with the limited scope that’s
> been proposed (and was previously discussed on GitHub). Of course, the
> working group can later decide to expand this scope if necessary; any
> extended scope would be handled as a separate adoption call to go into this
> document.
>
> Best,
> Tommy
>

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 19 Dec 2020 14:05:03 -0800

I think that based on the defined scope, any basic GREASE mechanisms that can be proved out to be useful and deployable would fit in scope for the H2 bis effort, but not any changes requiring a new ALPN without a further adoption call.

I also don’t think it’s a problem to let specifications of GREASE for H2 that are still more experimental to stay in separate documents as we get more experience. 

Best,
Tommy

> On Dec 19, 2020, at 12:43 PM, Ian Swett <[email-masked]> wrote:
> 
> 
> If people attempt to deploy GREASE for HTTP/2 more widely and it's found to be non-deployable, it seems like the second half of this bullet indicates GREASE should be dropped, but that's not the conclusion I'm getting from the above discussion.  Can you clarify that?
> 
> Making the protocol more resistant to ossification, so long as doing so does not affect interoperability
> 
> A question for the working group is: Are there servers that are going to actively pursue GREASE in H2?  We might do some, but it'll be limited in scope due to past issues.
> 
> Ian
>

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 20 Dec 2020 07:51:11 +0100

> scope due to past issues.

I'd say "it depends". I'm seeing two impacts of enabling GREASE on the
server side:

  - a lot of server-side users don't want to disclose what technologies
    they are using, and try hard to limit the visible signatures outside.
    By having a server start to emit random frame types, it will
    inevitably sign itself.

  - a large number of performance testing tools do not care about standards
    since the goal is to focus on performance, and I suspect that when such
    tools will be used against a grease-enabled server, they will report
    failures that will scare their users away.

All these could be addressed by having an option to disable greasing, but
in both cases users will be fooled. The first ones will consider the server
had purposely cheated on them. The second ones won't go past the initial
test and will declare the server as bogus. And by having an option to
explicitly enable greasing, well, I doubt users will enable it "for the
sake of improving the net" if they know it can cause some trouble to them.

If we could figure a way to make GREASE provide some benefit to server-side
users and encourage voluntary deployment, that would be nice. For example,
having search engines improve the ranking when greasing is detect could be
very effective for this. Just an idea.

Willy

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 21 Dec 2020 08:20:40 -0500

>     By having a server start to emit random frame types, it will

This is true.

> very effective for this. Just an idea.

This does not seem very voluntary!  Google says "jump!", website owners
say "how high?"

  - Dmitri.

---

From: Cory Benfield <[email-masked]>
Date: Tue, 22 Dec 2020 08:39:00 +0000

> On 20 Dec 2020, at 06:55, Willy Tarreau <[email-masked]> wrote:
> 

This is accurate. Server implementers are often caught in a bind between “want to conform tightly to the spec” and “get scored based on nonsensical microbenchmarks”. The end result is that plenty of servers take liberties with parts of the specification, and offer modes where you can disable their spec conformance features for speed. Even more just don’t bother to conform at all.

I think the bigger issue with greasing, though, is the failure mode Willy is outlining. Servers that fail to interoperate with a client when all other servers do are “broken”, even when they are morally in the right and the clients are morally in the wrong. Blame is always assigned to the most recent thing that changed, or the thing you can easily test with.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Dec 2020 15:25:15 +1100

> On 22 Dec 2020, at 7:39 pm, Cory Benfield <[email-masked]> wrote:
> 
> 
> 

My .02 - this makes me think that we need to carefully consider the incentives for (and against) adoption if we do introduce a new ALPN for greasing. Adding grease to the existing h2 is one thing; people can adopt it or not as they see fit, within the bounds of interoperability. OTOH if greasing is segregated into a separate ALPN identifier, it's going to create disincentives for adoption (and perhaps implementation) by some people. 

Cheers,