- From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
- Date: Thu, 31 Mar 2022 09:46:19 -0400
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Kazuho Oku <kazuhooku@gmail.com>
On Thu, Mar 31, 2022 at 01:06:45PM +0100, Lucas Pardue wrote: > It's noble to want a pattern but I don't think we have enough examples of > HTTP/2 extensions at the IETF to form consensus on one. My understanding is that communicating/negotiating feature support is among the raison d'être of HTTP/2 SETTINGS. Communicating and negotiating features is not new. For example, the *1977* RFC 731 for telnet has IAC WILL/IAC WONT and IAC DO/IAC DONT. I believe that draft-ietf-httpbis-priority for PRIORITY_UPDATE has serious omissions in this regard -- communicating and negotiating use of the optional feature -- especially since the draft recognizes limitations of PRIORITY and proposes an alternative to provide substantially overlapping functionality. For example: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-priority-12#section-2.1.1 makes an assumption which I find incorrect. Similarly, if the client receives SETTINGS_NO_RFC7540_PRIORITIES with value of 0 or if the settings parameter was absent, it SHOULD stop sending PRIORITY_UPDATE frames (Section 7.1), since those frames are likely to be ignored. My server (lighttpd) parses and discards PRIORITY frames, but I am planning on implementing the coarser, but simpler, PRIORITY_UPDATE, as well as supporting the proposed HTTP request header Priority. draft-ietf-httpbis-priority does not currently provide a clean way to communicate server HTTP/2 support preference for PRIORITY_UPDATE, but not PRIORITY, to the client. Using HTTP/2 SETTINGS appears to me to be a simple and an appropriate place to communicate this. Cheers, Glenn
Received on Thursday, 31 March 2022 13:46:40 UTC