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 14:55:49 -0700
Message-ID: <CAP+FsNcmwr7+=iCw1FZW6F2JdHE33ZeqGMqpx4rMp6092o0pMg@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>
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.
> >> >>
> >> >
> >
> >
>
Received on Tuesday, 1 October 2013 21:56:17 UTC

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