On Fri, Nov 10, 2017 at 3:52 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > 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? > > obviously extensions can collide - that's not a very practical problem when they are opt-in. > Best regards, Julian > >
Received on Saturday, 11 November 2017 23:01:39 UTC