- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Sat, 11 Nov 2017 23:07:18 +0200 (EET)
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Patrick McManus <mcmanus@ducksong.com>, Cory Benfield <cory@lukasa.co.uk>
>> Doesn’t the introduction of a new pseudo-header field violate RFC 7540 >> Section 8.1.2.1, which says endpoints MUST NOT generate new pseudo-header >> fields? >> >> Or is the position that that MUST NOT implicitly applies only if there are >> no negotiated extensions in use? >> >> >right - negotiating an extension via 7540 section 5.5 is an opt-in >procedure that lets you do just about anything you agree to.. I note that new pseudo-headers are not mentioned. 5.5. Extending HTTP/2 https://tools.ietf.org/html/rfc7540#section-5.5 " HTTP/2 permits extension of the protocol. Within the limitations " described in this section, protocol extensions can be used to provide " additional services or alter any aspect of the protocol. Extensions " are effective only within the scope of a single HTTP/2 connection. and " Extensions are permitted to use new frame types (Section 4.1), new " settings (Section 6.5.2), or new error codes (Section 7). Registries " are established for managing these extension points: frame types " (Section 11.2), settings (Section 11.3), and error codes " (Section 11.4). This makes unclear that extensions are permitted to use new pseudo header fields or other elements mentioned on HTTP/2 which are not listed on here. Of course you can change anything by saying that specification updates RFC 7540. / Kari Hurtta
Received on Saturday, 11 November 2017 21:07:49 UTC