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

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

Received on Friday, 18 July 2014 02:57:00 UTC