Re: Design: Ignored Unknown Frame Types and Intermediaries

[James M Snell <[e-mail]>]

-1. "ignore it" is not a sufficient answer to ensure interoperability
on the new extension points being defined. This needs to be tightened
up.

On Sun, May 12, 2013 at 11:15 AM, Roberto Peon <[e-mail]> wrote:
> I believe that the simplest thing is that, when you don't understand it, you
> ignore it.
>
> If that frame was required at some semantic level, then you should have
> rev'd the version number or changed the version string in some other way at
> the start of communication. That is easy and robust.
>
> This does imply that changing any state which the baseline protocol of that
> version depends upon is a no-no, but doesn't preclude changing state which
> the baseline protocol of that version *doesn't* know about.
>
> Making that a MUST, i.e. something like:
> And endpoint may use frames with opcodes other than those defined in this
> specification, however it MUST NOT do so if ignoring such a frame would
> cause an unexpected stream or session error, either directly or indirectly.
> -=R
>
>
> On Sat, May 11, 2013 at 9:58 PM, Yoav Nir <[e-mail]> wrote:
>>
>>
>> On May 11, 2013, at 6:27 PM, James M Snell <[e-mail]> wrote:
>>
>> > In the current draft, endpoints are required to "ignore" unknown and
>> > unsupported frame types. What's not yet clear, however, is whether
>> > such frames are required to be forwarded on by intermediaries that do
>> > not support them.
>> >
>> > In other words, A talks to C via reverse proxy B. A sends a stream
>> > that includes EXTENSION_FRAME_TYPE that is unknown to B. Is B...
>> >
>> > A) Required to drop the frame silently without forwarding it on to C
>> > B) Required to always forward the frame on to C
>> > C) Neither, B can do whatever it wants
>> >
>> > There is an obvious impact here on the future deployment of new
>> > extension frame types. If the answer is A or C, we'll have to wait on
>> > infrastructure support to use new frame types, which would be
>> > unfortunate.
>> >
>> > - James
>>
>> I think (C) is the only answer. Consider two types of proxies: an SSL
>> accelerator and a firewall. The SSL accelerator doesn't want to break
>> anything, so it will forward everything (B), while a firewall doesn't let
>> things pass which it doesn't understand (A). I think this will be the
>> behavior for these two kinds of proxy regardless of what we specify.
>>
>> Since the UA can never know in advance what the server will support, there
>> has to be some "extension support discovery" anyways. Perhaps if we had that
>> in the SETTINGS frame, the proxy could filter out.  For example, add a
>> SETTINGS_SUPPORTED_EXTENSION, which will hold an extension supported by the
>> sender. You will need multiple settings values for multiple extensions. The
>> server would send the same list as the client, filtered down to the list of
>> extensions that it supports. A proxy could trim the list further to remove
>> things it's going to drop.
>>
>> Yoav
>
>