W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: HTTP/2 extensions and proxies

From: James M Snell <jasnell@gmail.com>
Date: Tue, 1 Oct 2013 12:57:32 -0700
Message-ID: <CABP7Rbfi49swaJog9S8847c-pq=k34BgOzSSgOrDpm1dxZXWgg@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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 19:58:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC