Re: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt

[Patrick McManus <[e-mail]>]

I'm with Mike. It also gives the rather more radical example of changing
the layout of the HEADERS frame, which is not a manifestation of the
enumerated mechanisms either and would certainly violate otherwise
normative requirements of non-extended 7540.. the "limitations" it is
referring to is fundamentally the need for opt-in for this kind of change -
not a limitation against the change itself.


On Sun, Nov 12, 2017 at 5:33 AM, Mike Bishop <[e-mail]> wrote:

> "any aspect of the protocol" seems clear enough to me.  Though perhaps it
> was an oversight not to have a registry for new pseudo-headers.
>
> -----Original Message-----
> From: hurtta@[192.168.0.26] [mailto:hurtta@[192.168.0.26]] On Behalf Of
> Kari Hurtta
> Sent: Sunday, November 12, 2017 5:07 AM
> To: HTTP Working Group <[e-mail]>
> Cc: Kari Hurtta <[e-mail]>; Patrick McManus <
> [e-mail]>; Cory Benfield <[e-mail]>
> Subject: Extending HTTP/2 | Re: New Version Notification for
> draft-mcmanus-httpbis-h2-websockets-00.txt
>
> >> 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
>
>