Re: HTTP/2 extensions and proxies

I think you're missing what I'm saying, or I'm not saying it clearly enough.
I'll try to restate.

In mode 1, where the proxy has negotiated "http2" and has NOT negotiated
"experimental-http2"
The proxy MAY remove frames it does not understand.
Endpoints MUST NOT emit frames which, if removed, would desynchronize state.
A proxy which exists for security reasons would likely chose this mode.

In mode 2, where the proxy HAS negotiated "experimental-http2",
The proxy MUST NOT remove unknown frames*.
Endpoints MAY emit frames which, if removed, would desynchronize state.
A proxy which exists for performance reasons might chose this mode.
This mode allows for arbitrary experimentation, including state-m

*Perhaps there is a point-to-point or end-to-end bit or whatever, but if
so, that is in addition to the above, and cannot supplant it.

Neither end-to-end nor point-to-point signifies that removal would cause
state desynchronization, and in the end, this is what we care about.
-=R


On Tue, Oct 1, 2013 at 12:57 PM, James M Snell <jasnell@gmail.com> wrote:

> On Tue, Oct 1, 2013 at 12:31 PM, Roberto Peon <grmocg@gmail.com> wrote:
> > Doing a RST_STREAM (which, arguably would be insufficient for the kind of
> > error that you're talking about) unnecessarily removes the ability to
> > experiment with hint-like extensions, as I've said a number of times
> before.
> >
>
> And as I have demonstrated a number of times before, taking the
> approach you suggest unnecessarily removes the ability to experiment
> with non-hint-like extensions. Given that the intermediary has no way
> of knowing what it is dealing with, the safest and only reliable
> option is to apply an All or Nothing policy.
>
> The RST_STREAM is more than sufficient for the kind of error I'm
> talking about. Specifically, it says, "I received something on this
> stream I didn't expect and don't want, so I'm terminating the stream".
> I fail to see how that is insufficient.
>
> That said, however, you and I have had this conversation before and I
> have no desire to go around on it again. Left only to you and I we
> likely would not come to an agreement.
>
> - James
>
> > If a proxy hasn't stated that it will not drop frames, then the only
> > non-standard frames allowed are those which, if dropped, cause no
> > desynchronization.
> > As an example, frames that state priority in some new way should be
> > perfectly safe and allowed. If dropped, no correctness is sacrificed.
> >
> > -=R
> >
> >
> > On Tue, Oct 1, 2013 at 12:22 PM, James M Snell <jasnell@gmail.com>
> wrote:
> >>
> >> On Tue, Oct 1, 2013 at 12:11 PM, Martin Thomson
> >> <martin.thomson@gmail.com> wrote:
> >> >[snip]
> >> > If we need end-to-end extensions, then intermediaries need to ignore,
> >> > but
> >> > pass, unknown stuff. However, I think that we need to allow for
> >> > intermediaries that don't want to assume the risks associated with
> >> > extensions and allow intermediaries to drop unknown frames, but only
> if
> >> > they
> >> > drop *all* unknown frames.
> >>
> >> -1 .. if the intermediary needs to drop unknown frames, then it needs
> >> to RST_STREAM. Allowing the intermediary to silently drop frames
> >> midstream can lead to potential disaster. Either let everything thru,
> >> or let nothing thru. Period.
> >>
> >
>