Re: Getting to Consensus on 1xx Status Codes (#535)

Julian's proposal has the problem of allowing for/requiring headers which
are not flow controlled, and with no restriction on the number.
That makes me feel uncomfortable, however, if that could be reasonably
addressed I'd be comfortable supporting it.
Use of HEADERS in this way would potentially preclude other uses of
intermediate HEADERS, and would complicate the current spec.

I still feel support for 1XX is mostly unnecessary for H2, so option #2 (as
I understand it) is preferable.
-=R


On Thu, Jul 17, 2014 at 7:56 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 18/07/2014 5:57 a.m., Julian Reschke wrote:
> > On 2014-07-17 18:45, Martin Thomson wrote:
> >> On 16 July 2014 22:40, Mark Nottingham <mnot@mnot.net> wrote:
> >>> 1) Your preferred outcome (if any)
> >>
> >> I've described this elsewhere.
> >>
> >> We've very few examples upon which to base this decision: 100 is
> >> generally just bad, 101 is generally agreed to be unnecessary, and 102
> >> is deprecated.  But the pattern that I'm seeing here is that these are
> >> functions that generally related to protocol mechanics.
> >>
> >> The reason we agreed that 100-continue was OK to drop was that we had
> >> something roughly equivalent in WINDOW_UPDATE.  The reason that we all
> >> agree 101 is unnecessary is that we have ALPN and Upgrade (from
> >> HTTP/1.1).
> >>
> >> My hypothesis is that mechanisms that operate at this level are best
> >> addressed at the framing layer and should be constructed there.
> >> Julian's proposal ports a *mechanism* from HTTP/1.1, not a feature.
> >>
> >> I think that we're fine as we are now.
> >>
> >> If someone wants to define 107 (Gossip about Sheryl's choice in
> >> clothing), then that's how that might manifest in HTTP/1.1, but we can
> >> just make an extension frame for that in HTTP/2.  And I'm guessing
> >> that the HTTP/2 extension will deploy with a much higher success rate.
> >
> > The drawbacks are:
> >
> > - you'll need one extension per status code
>
> OR, group of codes. ie 107-110 Gossip about Sherly, Andys RSS feed, Bobs
> blog.
>
> >
> > - 1.1/2 gateways won't know how to translate new codes
>
> In accordance with 1xx semantics for compatibility with 1.0 the default
> action is drop 1xx. This can be defined for h2 gateways.
>
> >
> > ...unless we define a generic extension that can transport them all.
>
> Or specify that they can be dropped at any time by gateways receiving them.
>
> I am currently planning to implemet 2->1.1 gateway with WINDOW_UPDATE=0
> and Expect:100-continue on POST and PUT. Still unsure of some 1.1->2
> cases, but with increased 100-continue usage implied by 2->1.1 it seems
> more likely to be useful and/or needed.
> If the WG can come up with a better mechanism than WINDOW_UPDATE (or
> HEADERs+:status=100 to translate the mechanism I will look at it.
>
> Amos
>
>
>