- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 30 Jul 2019 05:51:11 +0200
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: Mike Bishop <mbishop@evequefou.be>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Brad Lassey <lassey@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 30, 2019 at 10:06:14AM +0900, Kazuho Oku wrote: > 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. 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
Received on Tuesday, 30 July 2019 03:51:41 UTC