Re: Setting to disable HTTP/2 Priorities

2019年7月30日(火) 4:41 Mike Bishop <mbishop@evequefou.be>:
>
> 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.

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

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


-- 
Kazuho Oku

Received on Tuesday, 30 July 2019 01:06:51 UTC