- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 1 Oct 2013 14:55:49 -0700
- 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>
- Message-ID: <CAP+FsNcmwr7+=iCw1FZW6F2JdHE33ZeqGMqpx4rMp6092o0pMg@mail.gmail.com>
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