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

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

- 1.1/2 gateways won't know how to translate new codes

...unless we define a generic extension that can transport them all.

Best regards, Julian

Received on Thursday, 17 July 2014 17:57:41 UTC