Re: HTTP/2 extensions and proxies

I mean that when the proxy encounters unknown end to end frames on a
stream, it chooses to either allow them thru, or closes the stream.
On Oct 1, 2013 2:55 PM, "Roberto Peon" <grmocg@gmail.com> wrote:

> By 'All or Nothing', do you mean 'proxy drops all unknown' or 'proxy never
> drops unknown', or is it some other meaning?
> -=R
>
>
> On Tue, Oct 1, 2013 at 2:44 PM, James M Snell <jasnell@gmail.com> wrote:
>
>> On Tue, Oct 1, 2013 at 1:40 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> > I think you're missing what I'm saying, or I'm not saying it clearly
>> enough.
>> > I'll try to restate.
>> >
>>
>> I'm very clear about what you're suggesting...
>>
>> > 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
>> >
>>
>> What I'm saying is that these "modes" would apply only to hop-by-hop
>> frames that affect connection state. For end-to-end frames sent on a
>> stream, however, it ought to be possible to send them in either mode
>> with the All or Nothing semantics I've described.
>>
>> - James
>>
>> > *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.
>> >> >>
>> >> >
>> >
>> >
>>
>
>