Subject: Setting to disable HTTP/2 Priorities

From: Brad Lassey <[email-masked]>
Date: Thu, 25 Jul 2019 14:49:52 -0400

Hi all,
Lucas and I put together a draft to capture at least one of the ways
forward that were identified at the priorities side meeting yesterday
morning. Please have a look.

https://datatracker.ietf.org/doc/draft-lassey-priority-setting/
https://github.com/bslassey/priority-setting

-Brad

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 25 Jul 2019 15:17:47 -0400

>From the draft:

" 3.  The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter
" 
"    This document adds a new SETTINGS parameter to those defined by
"    [RFC7540], Section 6.5.2.
" 
"    The new parameter name is SETTINGS_ENABLE_HTTP2_PRIORITIES.

Including "HTTP2" in the name is superfluous:  Since this is an
HTTP/2 setting, it deals with HTTP/2 priorities.

Or was "HTTP2" added to the name to differentiate it from possible
future priority mechanisms?  In that case, I suggest s/HTTP2/RFC7540/

  - Dmitri.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 25 Jul 2019 20:35:34 +0100

Hey Dmitri,

> HTTP/2 setting, it deals with HTTP/2 priorities.

I agree with your observation

> future priority mechanisms?  In that case, I suggest s/HTTP2/RFC7540/

My observation is that WG is using a range of terms to refer to

* HTTP/2's tree-based priority model
* signalled using HTTP/2 frames
* HTTP/3's HTTP/2-inspired-tree-based priority model
* signalled using HTTP/3 frames

Refining these terms would help in generak IMO, and would probably get
reflected back into the name of this setting.

Lucas

---

From: Brad Lassey <[email-masked]>
Date: Thu, 25 Jul 2019 16:06:38 -0400

On Thu, Jul 25, 2019 at 3:35 PM Lucas Pardue <[email-masked]>
wrote:

> Hey Dmitri,
>
>
> On Thu, Jul 25, 2019 at 8:21 PM Dmitri Tikhonov <
> [email-masked]> wrote:
>
>> From the draft:
>>

> I think this is true, where HTTP2 here refers to RFC7540 (and the priority
scheme defined there) and it would be possible for two peers to negotiate a
different priority scheme via and extension to use for the session.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 26 Jul 2019 05:19:12 +0200

Hi Brad,

> https://github.com/bslassey/priority-setting

While I think that's a very wise approach, I think it would have more
success if it doesn't change the default behaviour. I mean, some
developers on both sides have gone through great length implementing
priorities and expecting now that they should suddenly have to add
extra code to continue to use them might be difficult to accept.
Conversely, all those who didn't implement them would have a great
incentive to add a few lines of code to signal their lack of support
and immediately expect a better experience. Thus I think priorities
should remain enabled unless signaled as disabled by this new setting.

And for having been late to implement them into haproxy (still not
present), I'd definitely adopt this proposal as a temporary measure
if it helps improve user experience!

Cheers,
Willy

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 25 Jul 2019 23:48:40 -0400

Hi Willy!

> should remain enabled unless signaled as disabled by this new setting.

The aim is to maintain todays default behavior of endpoints supporting H2.
This is achieved by defining the initial value of the setting as 1;
endpoints "opt out" by sending 0.

Do you think we have mis-specced this compared to our aim?

> if it helps improve user experience!

That's an interesting data point, thanks for sharing.

Cheers
Lucas

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 26 Jul 2019 07:24:49 +0200

Hi Lucas,

> endpoints "opt out" by sending 0.

Ah OK, thanks for clearing this out!

> Do you think we have mis-specced this compared to our aim?

No, but I might have misread it, I'll re-read. I also noticed that the
beginning of the wording in the abstract mentioned clients not supporting
priorities while they are usually the ones advertising them while servers
not supporting them is (in my opinion) the real concern here (except maybe
for PUSH). But I'll have another read with more caffeine :-)

Cheers,
Willy

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jul 2019 19:38:07 +0000

Both are issues.  I think the first order of business is to know whether the peer supports PRIORITY. If the client doesn't, the server might choose to be more aggressive about making its own inferences.  If the server doesn't, the client might as well save some bytes and might choose to delay low-priority requests on the assumption the server will be assuming the requests are in priority order.

-----Original Message-----
From: Willy Tarreau <[email-masked]> 
Sent: Friday, July 26, 2019 1:25 AM
To: Lucas Pardue <[email-masked]>
Cc: Brad Lassey <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Setting to disable HTTP/2 Priorities

Hi Lucas,

> Do you think we have mis-specced this compared to our aim?

No, but I might have misread it, I'll re-read. I also noticed that the beginning of the wording in the abstract mentioned clients not supporting priorities while they are usually the ones advertising them while servers not supporting them is (in my opinion) the real concern here (except maybe for PUSH). But I'll have another read with more caffeine :-)

Cheers,
Willy

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 30 Jul 2019 10:06:14 +0900

> Both are issues.  I think the first order of business is to know whether the peer supports PRIORITY. If the client doesn't, the server might choose to be more aggressive about making its own infere…

+1.

I think that the proposed settings is the right way to go. Even though
it is sometimes the issue with endpoints using priorities incorrectly
(e.g., a web browser assigning different "weights" based on the type
of the resource), introducing the proposed settings would be the
correct thing to do in order to sunset the H2 prioritization scheme.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 30 Jul 2019 05:51:11 +0200

On Tue, Jul 30, 2019 at 10:06:14AM +0900, Kazuho Oku wrote:
> 2019?7?30?(?) 4:41 Mike Bishop <[email-masked]>:
> >
> I think that the proposed settings is the right way to go.

I agree, this is fast and clean.

> Even though

I just have a practical question : does this mean I'll waste my time
if I implement H2 priorities in haproxy ? I mean, if there's a general
consensus that this is counter-productive or if browsers are thinking
about abandoning priorities, I probably have better to work on. If it's
only for certain corner cases that priorities should be abandoned and
that they are still valuable, I can continue to work on this. I'm
interested on any advice on this!

Thanks,
Willy

---

From: Mike Bishop <[email-masked]>
Date: Tue, 30 Jul 2019 14:34:49 +0000

Personal opinion, not backed by any browser stack:  Browsers have seen some benefits from the current prioritization scheme when implemented by both server and client.  If you are able to implement it, you'll likely improve your performance with browsers that currently send priority information.  When there's a new scheme, there will likely be some negotiation mechanism to determine what the peers support.  I doubt that the client with existing implementations will quickly rip them out; your work would continue to be leveraged while the replacement is being developed and by older browsers in the future.

I don't think it would be wasted work, particularly if your client population already sends priorities; however, it's likely that a few years from now, it would be less-exercised code that might need maintenance.  That's the balance you have to weigh; I don't know what the drop-off curve or the maintenance cost will look like.

Again, the point isn't that the priority scheme in RFC7540 doesn't provide benefit -- it's that it's over-general and therefore not getting good traction in the ecosystem.

-----Original Message-----
From: Willy Tarreau <[email-masked]> 
Sent: Monday, July 29, 2019 11:51 PM
To: Kazuho Oku <[email-masked]>
Cc: Mike Bishop <[email-masked]>; Lucas Pardue <[email-masked]>; Brad Lassey <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: Re: Setting to disable HTTP/2 Priorities

> correct thing to do in order to sunset the H2 prioritization scheme.

I just have a practical question : does this mean I'll waste my time if I implement H2 priorities in haproxy ? I mean, if there's a general consensus that this is counter-productive or if browsers are thinking about abandoning priorities, I probably have better to work on. If it's only for certain corner cases that priorities should be abandoned and that they are still valuable, I can continue to work on this. I'm interested on any advice on this!

Thanks,
Willy

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 30 Jul 2019 18:48:01 +0300 (EEST)

> future priority mechanisms?  In that case, I suggest s/HTTP2/RFC7540/

Why boolean ("ENABLE") ?

I suggests SETTINGS Parameter

SETTINGS_PRIORITY_SCHEME

with values

 • 0             Sender of SETTINGS frame indicates that
                 it does not process or send priority 
                 values

 • 1             Sender of SETTINGS frame indicates that
                 it process or send RFC7540 priorities

 • unknown value (for recipient of SETTINGS frame)

                 Sender of SETTINGS frame indicates that
                 it is willing process some priority information  
                 or that it sends some priority information
                 (but recipient of SETTINGS frame does
                  not recognize these priorities)

Default value for SETTINGS_PRIORITY_SCHEME is 1
( RFC7540 priorities aka current HTTP/2 tree priorities).

Peer of HTTP/2 connection should send SETTINGS frame
with SETTINGS_PRIORITY_SCHEME once

Peer of HTTP/2 connection may send second SETTINGS frame
with SETTINGS_PRIORITY_SCHEME if it's value is same
than which it is received for peer on SETTINGS frame.

That is:
    Suggest SETTINGS_PRIORITY_SCHEME once
    and send SETTINGS_PRIORITY_SCHEME second time
    after that when you agreed with peer.

That makes SETTINGS_PRIORITY_SCHEME switch to
new priority scheme (when that is defined).

/ Kari Hurtta

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 30 Jul 2019 17:51:36 +0100

Hi Kari,

> new priority scheme (when that is defined).

Boolean gives us the MVP for moving away from RFC7540 priorities. The
suggestion to allow also signalling "something else" is valid and has been
mentioned by some others, thanks for sharing your thoughts.
My personal concern is that making this too complicated may result in it
not getting exercised in practice. This, to my mind, includes picking
something that is a fit for HTTP/3 too.

How would you feel about an an alternative design that uses two settings?
I.e. one for RFC750 enablement, and another to enable a specific
prioritisation scheme.

HTTP/3 allows only one SETTINGS frame in each direction, so using that as a
negotiation mechanism has problems. Boolean unilateral adverts work better
in that case. We might want to say that HTTP/3 has RFC7540 priorities
always default to disabled and not specify a setting in the core draft to
enable them. Then, using additional boolean settings per scheme would allow
a more common approach to priority scheme selection across H2 and H3.

Regards
Lucas

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 31 Jul 2019 07:24:58 +1000

On Wed., 31 Jul. 2019, 02:56 Lucas Pardue, <[email-masked]>
wrote:

> HTTP/3 allows only one SETTINGS frame in each direction, so using that as
> a negotiation mechanism has problems. Boolean unilateral adverts work
> better in that case. We might want to say that HTTP/3 has RFC7540
> priorities always default to disabled and not specify a setting in the core
> draft to enable them. Then, using additional boolean settings per scheme
> would allow a more common approach to priority scheme selection across H2
> and H3.
>
> Regards
> Lucas
>

At the risk of bike-shedding, I think calling it "enable" is a bit of an
issue. The setting, as an advertisement of the sender's capability, should
say something like "will ignore" (for disabling 7540 priorities) or "can
understand" (for enabling some other scheme).

Unless we also feel the need to advertise "will not send"?

Cheers
-- 
Matthew Kerwin

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 31 Jul 2019 08:08:27 +0200

Hi Mike,

On Tue, Jul 30, 2019 at 02:34:49PM +0000, Mike Bishop wrote:
> Personal opinion, not backed by any browser stack:  Browsers have seen some
> benefits from the current prioritization scheme when implemented by both
> server and client.  If you are able to implement it, you'll likely improve
> your performance with browsers that currently send priority information.
> When there's a new scheme, there will likely be some negotiation mechanism to
> determine what the peers support.  I doubt that the client with existing
> implementations will quickly rip them out; your work would continue to be
> leveraged while the replacement is being developed and by older browsers in
> the future.

That was indeed the sense of my question. Since I'm seeing some discussion
around priorities, I was wondering if there's a general consensus around
dropping the existing scheme or that it's often counter-effective. I'm not
worried about doing it just for a few years, I was worried of doing it for
nothing :-)

Thanks!
Willy

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 31 Jul 2019 12:01:27 +0100

Hi Matthew,

> Unless we also feel the need to advertise "will not send"?

It's difficult for a server to guess at the client intent. Not sending
PRIORITY information is also a signal to prioritise the request with
default RFC7540 parameters (depend on root node with weight 16). So having
a clear signal from client to server along the lines of "I don't intend to
send, and don't infer any RFC7540 meaning from it" avoids that problem and
my impression from Montreal was that this is a desirable goal. In Montreal
we also discussed a possible experiment where the H2 PRIORITY frame
contents would be repurposed, which requires a compatible server to read it
correctly. In this case the signal would be more like "will send in an
RFC7540-incompatible format".

Lucas

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 31 Jul 2019 21:00:56 +0300 (EEST)

> Unless we also feel the need to advertise "will not send"?

Yes,

SETTINGS_ENABLE_* typically changes how HTTP/2 connection is
prosessed or allows some usages which otherwise produce
protocol error (example: SETTINGS_ENABLE_CONNECT_PROTOCOL).

Therefore these these typically allows only 0 ⇒ 1 transitions.
Feature which is enabled, is not allowed to be turned off because
it may effect handling of frames which are already sent by
other peer.

Therefore I think that

    SETTINGS_PROVIDE_HTTP2_PRIORITIES

is better name than

    SETTINGS_ENABLE_HTTP2_PRIORITIES

In other words this does not chahneg parsing of HTTP/2
frames. Even when this is set to 0, sending priorities
does not cause protocol error.

In SETTINGS_PROVIDE_HTTP2_PRIORITIES server asks
client to provide (or not provide) http/2 tree 
priorities.

( Another possible name is

  SETTINGS_PROVIDE_TREE_PRIORITIES

)

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 31 Jul 2019 21:34:17 +0300 (EEST)

> Boolean gives us the MVP for moving away from RFC7540 priorities. The

( what is MVP ? )

> a more common approach to priority scheme selection across H2 and H3.

I perhaps interpret this incorrectly, but I try reword your design.

So  HTTP/2 you have SETTINGS paramaters

 • SETTINGS_PROVIDE_HTTP2_PRIORITIES (aka SETTINGS_ENABLE_HTTP2_PRIORITIES)
 • SETTINGS_HTTP3_PRIORITY_MASK

and on HTTP/3 you have on SETTINGS paramater

 • SETTINGS_HTTP3_PRIORITY_MASK

where SETTINGS_HTTP3_PRIORITY_MASK is enable mask (or bitmask) of
HTTP/3 priority schemes which sender of SETTINGS frame support.

Because SETTINGS_HTTP3_PRIORITY_MASK does not include bit for
HTTP/2 tree priorites, HTTP/3 does not support them.

Available HTTP/3 priority schemes is intersection (or "binary and")
between sent and received SETTINGS_HTTP3_PRIORITY_MASK.

Because HTTP/3 there is only one SETTINGS frame per direction,
sending of SETTINGS_HTTP3_PRIORITY_MASK can not delayed until
SETTINGS_HTTP3_PRIORITY_MASK received from peer is learned.

Therefore SETTINGS frame can not used to indicate selected
priority scheme (if there more than one priority scheme available).

So I assume that HTTP/3 client indicates selected priority scheme
by just using it.

I my guess correct?

( If priority mask style desing is allowed to include bit
  for HTTP/2 tree priorites, then SETTINGS_PROVIDE_HTTP2_PRIORITIES
  and SETTINGS_HTTP3_PRIORITY_MASK SETTINGS parameters
  collapse to one SETTINGS paramater:

    SETTINGS_PRIORITY_MASK

)

/ Kari Hurtta

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 31 Jul 2019 20:11:14 +0100

> client to provide (or not provide) http/2 tree

Thanks. Along that line of thinking, maybe its simpler just to represent
this as an opt out flag? E.g. SETTINGS_RFC7540_PRIORITY_OPT_OUT which can
only ever be a value of 1. By default H2 endpoints have opted in and they
have a freedom to opt out. However, once they do so there are no take
backs.

Lucas

P.s.the cynic in me would call this SETTINGS_PREXIT. An endpoint that
invokes RFCticle 9050,  needs to select a new deal or crash out to WT(FIF)O
priorities.

---

From: Kari Hurtta <[email-masked]>
Date: Wed, 31 Jul 2019 22:10:44 +0300 (EEST)

>Do you think we have mis-specced this compared to our aim?

There is  "If a client or server does not send the setting, the peer 
SHOULD NOT make any assumptions about its support for HTTP/2 priorities.".

https://datatracker.ietf.org/doc/draft-lassey-priority-setting/?include_text=1

------------
3.  The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter

   This document adds a new SETTINGS parameter to those defined by
   [RFC7540], Section 6.5.2.

   The new parameter name is SETTINGS_ENABLE_HTTP2_PRIORITIES.  The
   value of the parameter MUST be 0 or 1 to indicate not supporting or
   supporting HTTP/2 priorities respectively.  If either side sends the
   parameter with a value of 0, clients SHOULD NOT send priority frames
   and servers SHOULD NOT make any assumptions based on the presence or
   lack thereof of priority frames.  If both sides send the parameter
   with a value of 1, then both parties MAY use HTTP/2 priorities as
   they see fit.  A sender MUST NOT send the parameter with the value of
   0 after previously sending a value of 1.  If a client or server does
   not send the setting, the peer SHOULD NOT make any assumptions about
   its support for HTTP/2 priorities.
-------------

This section indicates that default value is undefined, because it says
that if SETTINGS_ENABLE_HTTP2_PRIORITIES is not seen, the peer SHOULD NOT 
make any assumptions about other ends support for HTTP/2 priorities.

-------------
4.1.  A New HTTP/2 Setting

   This document registers an entry in the "HTTP/2 Settings" registry
   that was established by Section 11.3 of [RFC7540].

   Name: SETTINGS_ENABLE_HTTP2_PRIORITIES

   Code: 0xTBD

   Initial Value: 1

   Specification: This document
--------------

If initial value for SETTINGS_ENABLE_HTTP2_PRIORITIES is really 1,
then peer may assume that other ends supports HTTP/2 priorities
until SETTINGS_ENABLE_HTTP2_PRIORITIES is seen.

So there is inconsistence between chapters.

/ Kari Hurtta

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 31 Jul 2019 20:14:24 +0100

> https://datatracker.ietf.org/doc/draft-lassey-priority-setting/?include_text=1

Agreed. We should tighten this up for something that is practically
deployable and meets the needs of implementers. Ideally we can take
feedback so far and iterate through the design team process.

Cheers
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 31 Jul 2019 20:22:47 +0100

>   collapse to one SETTINGS paramater:

When you put it like that, the MASK design has elegance in that it
specifies a signal mechanism for priority scheme selection. That has
attractive properties because it avoids each scheme having to define a
discovery mechanism.

Lucas

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 1 Aug 2019 09:04:38 +1000

> it may effect handling of frames which are already sent by
"Typically"?  In the old testament there is only one 'ENABLE' type setting,
and its initial value is 1.  The extended canon introduces a single new
setting that works the other way.

Also remember: the initial handshake includes settings, so these can be
disabled from the beginning; and: settings have an ACK, so you have a
definite epoch where "already sent" no longer applies.

But yeah. what's significant about them is, 1 or 0, what they say is: "the
recipient of this setting must/must not send a frame of this type".  I.e.
the sender of the setting says, "I will/won't understand these frames".
It's not "I will/won't *send* them myself."  I think that means we're
agreeing that 'ENABLE' isn't the right word.

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 1 Aug 2019 09:09:43 +1000

On Wed, 31 Jul 2019 at 21:02, Lucas Pardue <[email-masked]>
wrote:

> my impression from Montreal was that this is a desirable goal.
>

A hint, then.  Different from all the "I will understand if you do this"
settings.  I feel it's important to reiterate, though, that the setting *can
not* say "don't infer meaning from it" -- you can't use a setting to tell
the other end how to respond to your frames, only how you will respond to
theirs.

What happens if the client connects to a server that doesn't understand the
setting?  Are you using it as a negotiation-lite signal, so the client
won't switch off its 7540-priority-tree code path until both ends have said
they're happy doing so?

> In Montreal we also discussed a possible experiment where the H2 PRIORITY
> frame contents would be repurposed, which requires a compatible server to
> read it correctly. In this case the signal would be more like "will send in
> an RFC7540-incompatible format".
>
> Lucas
>

Eurgh, why?  Are we that short on frame types?

Cheers

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 1 Aug 2019 07:06:31 +0300 (EEST)

> setting that works the other way.

I stand corrected.

> agreeing that 'ENABLE' isn't the right word.

Yes.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 1 Aug 2019 07:41:52 +0300 (EEST)

> invokes RFCticle 9050,  needs to select a new deal or crash out to WT(FIF)O

If peer implements HTTP/2 (RFC7540) tree priorities but is willing
also to use other priority scheme, then either

 • HTTP/2 (RFC7540) tree priorities must be active until
   both peers have sent and received SETTINGS frame
   with HTTP/2 (RFC7540) tree priority opt out, 

or

 • peer needs delay sending SETTINGS frame with HTTP/2 (RFC7540) tree 
   priority opt out until it is received SETTINGS frame 
   which suggests some other priority scheme (or until server
   is received HTTP request with some other priority scheme).

So it is important to consider how selecting some other priority scheme
and opting out HTTP/2 (RFC7540) tree priorities interacts.

I notice that SETTINGS parameter, which suggests of some other priority scheme 
( or set of schemes), work as HTTP/2 (RFC7540) tree priority opt
out IF initial value for that SETTINGS parameter is allowed to be unset.

So SETTINGS_PRIORITY_MASK which I mentioned on other post may
work if it's initial value is unset on HTTP/2 ( but 0 on HTTP/3).

On that case

HTTP/2 (RFC7540) tree priorities are active until peer
is sent AND received SETTINGS frame with SETTINGS_PRIORITY_MASK
parameter.

So to crash out to WT(FIF)O priorities is sending SETTINGS frame with
SETTINGS_PRIORITY_MASK value 0 (and receiving SETTINGS frame with
any SETTINGS_PRIORITY_MASK value).

In that case HTTP/2 (RFC7540) tree priorities also remain active
if either peer does not implement SETTINGS_PRIORITY_MASK parameter.

( Assuming that HTTP/2 (RFC7540) tree priorities are implemented. )

I do not know can initial value for some SETTINGS paramater to be
considered unset where unset is special meaning.

If SETTINGS_PRIORITY_MASKS can not have initial unset value but 
it's value is allowed to include bit for HTTP/2 tree priorities,
it also works. In that case initial value on HTTP/2 for
SETTINGS_PRIORITY_MASKS includes only bit for HTTP/2 tree priorites.

Calculating of new available priority scheme set must be delayed
until SETTINGS frame with SETTINGS_PRIORITY_MASKS paramater
is sent AND received.

/ Kari Hurtta

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Aug 2019 06:41:08 +0200

> feedback so far and iterate through the design team process.

I think the confusing part comes from the ENABLE word in the setting
name. We could proceed differently by exchanging a supported model
for priorities :  SETTINGS_HTTP2_PRIORITY_MODEL
It could then take the following values :

    0 (default) : as specified in RFC7540
    1           : priorities not sent and silently ignored
    2 and above : to be documented in future specifications

This way it seems more natural to consider that unless advertised, we
stay on RFC7540 and nothing changes.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Aug 2019 06:48:20 +0200

> stay on RFC7540 and nothing changes.

I've just seen the other proposal for SETTINGS_PRIORITY_SCHEME (which
sounds better) and which seems fairly similar, I'm fine with this as
well of course.

Willy

---

From: Kari Hurtta <[email-masked]>
Date: Thu, 1 Aug 2019 08:09:16 +0300 (EEST)

> stay on RFC7540 and nothing changes.

This is almost same than my SETTINGS_PRIORITY_SCHEME suggestion.

It have only 1 and 0 flipped.

https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0140.html

Then incompatibility with HTTP/3's SETTINGS frame was cited.

https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0141.html

/ Kari Hurtta

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Aug 2019 08:11:42 +0200

Hi Kari,

> This is almost same than my SETTINGS_PRIORITY_SCHEME suggestion.

Yes that's what I mentioned afterwards, I've read messages in different
order and found yours after I responded above :-)

Thus I fully support it of course.

> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0140.html

Yep. I tend to prefer keeping zero the default, it generally is easier
to assume that "unset == not changed from default". But this is a very
minor detail.

> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0141.html

Noted as well.

Thanks,
Willy