Re: HTTP/2 extensions and proxies

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.
>> >>
>> >
>
>

Received on Tuesday, 1 October 2013 21:45:16 UTC