Re: draft-ietf-httpbis-http2-latest, 5.5 Extending HTTP/2

>
> > » Implementations MUST ignore unknown or unsupported values in all
> > » extensible protocol elements. Implementations MUST discard frames that
> > » have unknown or unsupported types.
> >
> > I read that "MUST ignore" that these unknown or unsupported values
> > are not read by proxy and when packet is generated to upstream or
> > downstream default values are used for reserved fields.
> That's right.  If someone sets a setting that you don't understand,
> even if you are just copying stuff into another session, don't
> advertise that setting.  If someone sets a flag you don't understand,
> don't copy that across.  You might be signing on to something you
> don't understand.

Is that same for colon-started headers?
i.e. Must a proxy filter out colon-started headers that it doesn't
understand?

Thanks,



On Sat, Jul 12, 2014 at 2:34 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 11 July 2014 08:45, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote:
> > » HTTP/2 permits extension of the protocol. Protocol extensions can be
> > » used to provide additional services or alter any aspect of the
> > » protocol, within the limitations described in this section. Extensions
> > » are effective only within the scope of a single HTTP/2 connection.
> >
> > So proxy which uses HTTP/2 both downstream and upstream, must clear
> > are  unknown or unsupported values before forwarding to
> > upstream or downsream. (That means that reserved fields or bits
> > are put to default values given on this documentation. )
> > And proxy must discard unknown or sunsupported frames.
>
> This is correct.  Bits that the proxy doesn't know about (like flags),
> can't be copied across.
>
> In other words: no extension smuggling.
>
> > » Implementations MUST ignore unknown or unsupported values in all
> > » extensible protocol elements. Implementations MUST discard frames that
> > » have unknown or unsupported types.
> >
> > I read that "MUST ignore" that these unknown or unsupported values
> > are not read by proxy and when packet is generated to upstream or
> > downstream default values are used for reserved fields.
>
> That's right.  If someone sets a setting that you don't understand,
> even if you are just copying stuff into another session, don't
> advertise that setting.  If someone sets a flag you don't understand,
> don't copy that across.  You might be signing on to something you
> don't understand.
>
> >    +--------------------+
> >    |  WWW server        |
> >    +--------------------+
> >            |
> >          HTTP/2
> >            |
> >    +--------------------+
> >    |      proxy         |
> >    +--------------------+
> >            |
> >          HTTP/2
> >            |
> >   +--------------------+
> >   |  WWW browser       |
> >   +--------------------+
> >
> >
> > So here WWW server and WWW browser can not communicate
> > with using any extension which is not supported by proxy
> > even when extension does not change semantics of existing
> > protocol components.
>
> Yeah, proxies will have that effect.  Preventing that sort of
> communication is often a goal of a proxy.
>
>