- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 10 Nov 2017 08:52:51 +0100
- To: Patrick McManus <mcmanus@ducksong.com>, Cory Benfield <cory@lukasa.co.uk>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, hybi <hybi@ietf.org>
On 2017-10-15 20:39, Patrick McManus wrote: > > > On Sun, Oct 15, 2017 at 11:43 AM, Cory Benfield <cory@lukasa.co.uk > <mailto:cory@lukasa.co.uk>> wrote: > > 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.. the spec > tries to draw a bright line between extensions that can be ignored > safely and those that cannot and need to be negotiated (such as this > one). Enjoy the example in there about changing the layout of the > HEADERS frame :). This is also why extensions are hop to hop. > > one of the reasons I chose the pseudo header to only apply to CONNECT is > already very special purpose - so the exception doesn't pollute very far > as a practical matter. > ... But still, it leaks. What if a different extension that wants to co-exist with this one wants to define a pseudo header field with the same name? Best regards, Julian
Received on Friday, 10 November 2017 07:53:23 UTC