RE: Setting to disable HTTP/2 Priorities

[Mike Bishop <[e-mail]>]

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 <[e-mail]> 
Sent: Monday, July 29, 2019 11:51 PM
To: Kazuho Oku <[e-mail]>
Cc: Mike Bishop <[e-mail]>; Lucas Pardue <[e-mail]>; Brad Lassey <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: Setting to disable HTTP/2 Priorities

On Tue, Jul 30, 2019 at 10:06:14AM +0900, Kazuho Oku wrote:
> 2019?7?30?(?) 4:41 Mike Bishop <[e-mail]>:
> >
> > 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.

I agree, this is fast and clean.

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

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