HTTP/2: implement RFC 9218 Extensible Prioritization Scheme for HTTP. #552
Conversation
|
@arturobernalg Before we can do anything of this kind we must ensure conformance with RFC 9113 first. |
ok2c
force-pushed
the
master
branch
4 times, most recently
from
8fb1d8e to
bf7d524
Compare
|
@arturobernalg This is a big change. I have no bandwidth to carefully read through RFC 9218 at the moment. What I can do to review your changes for impact on the existing code and APIs. The rest becomes your area of responsibility, if you are willing to maintain this feature. Please also consider how stable it is and whether one release cycle should be enough to stabilize it or it should be marked experimental and go though several release cycles. |
arturobernalg
force-pushed
the
rfc9218
branch
4 times, most recently
from
a457f09 to
e1d5baf
Compare
arturobernalg
changed the title
@ok2c ACK — I’ll can own RFC 9218: client emission gated by |
| return new PriorityParams(null, null); | ||
| } | ||
|
|
||
| final CharArrayBuffer buf = new CharArrayBuffer(headerValue.length()); |
There was a problem hiding this comment.
@arturobernalg Please do not do that. There is no need to create a copy of the header value. The parser can work with any CharSequence. Can't you re-use MessageSupport parsing routines here?
Otherwise, looks good.
There was a problem hiding this comment.
@ok2c please do another pass
Add PRIORITY_UPDATE (0x10) and SETTINGS_NO_RFC7540_PRIORITIES (0x9). Client emits before HEADERS on opt-in; server accepts and applies. Wire into multiplexer + Priority header utils + tests.
There was a problem hiding this comment.
@arturobernalg This feature is now your area of responsibility.
This PR adds core support for RFC 9218: we advertise SETTINGS_NO_RFC7540_PRIORITIES=1, gate PRIORITY_UPDATE emission on the peer’s setting (or pre-SETTINGS), parse/accept PRIORITY_UPDATE frames in the base muxer, and introduce PriorityParamsParser for the Priority header (u/i members, tolerant parsing).