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

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.

Received on Friday, 11 July 2014 17:35:13 UTC