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

Re: HTTP/2 extensions and proxies

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 1 Oct 2013 12:31:28 -0700
Message-ID: <CAP+FsNeh72JDDS4+zRB7LtEKigDzwr7Kbcf3GL39YFpFpZuivg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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.

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:31:55 UTC

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