RE: Setting to disable HTTP/2 Priorities

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 <w@1wt.eu> 
Sent: Friday, July 26, 2019 1:25 AM
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: Brad Lassey <lassey@chromium.org>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Setting to disable HTTP/2 Priorities

Hi Lucas,

On Thu, Jul 25, 2019 at 11:48:40PM -0400, Lucas Pardue wrote:
> 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.

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

Received on Monday, 29 July 2019 19:38:32 UTC