Re: #535: No 1xx Status Codes

On 15/07/2014 9:43 p.m., Willy Tarreau wrote:
> Hi Julian,
> 
> On Tue, Jul 15, 2014 at 10:35:32AM +0200, Julian Reschke wrote:
>> On 2014-07-15 10:13, Mark Nottingham wrote:
>>> My .02 -
>>>
>>> Status codes have semantic "heft" in the protocol, and if an entire class 
>>> of them is both poorly supported and has poor interest, it's not 
>>> unreasonable to consider deprecating that class of status codes. If 
>>> someone tries to use it in the future, they're going to be disappointed, 
>>> because it isn't supported in software and APIs; that semantic won't be 
>>> useful to express or expect (as was found with 102).
>>
>> But we are not deprecating them, we are *removing* them.
>>
>>> Persisting 1xx status codes has a real cost; besides the obvious cost of 
>>> requiring HTTP/2 implementations to code for them, test them, and support 
>>> them, there's also the cost of handling the interoperability problems when 
>>> they don't work.
>>
>> HTTP/1.1<->2 converters need to code for them anyway: in one case 
>> they'll drop them (requires detecting them), in the other case they 
>> forward them.
> 
> I could be wrong, but the only possible issues I'm seeing with them removed
> are :
> 
>   - H1->H2 gateways : have to respond 100-continue when getting an Expect
>     header field, possibly to later break the connection if the server aborts
>     the stream. I don't think it's a huge issue, it's similar to dealing with
>     302 on POSTs in my opinion (not easy either but necessary anyway).

I have not checked scenarios, but I suspect that these gateways can emit
the 100-continue on a WINDOW_UPDATE from the server end of their h2
connection.

> 
>   - H2->H1 gateways : may benefit from sending Expect in outgoing POST requests
>     or may have to do it over persistent connections, and to strip any 100
>     response. This is a difficulty which already has to be dealt with in pure
>     1.1.

Indeed. This is probably a good recommendation for a SHOULD on emitting
Expect on the 1.1 connection, then emit a WINDOW_UPDATE down the h2
connection on recipt of the 100-continue or the Expect timeout.

If the above h1->h1 is correct this method will allow both types of
gateway to work in-sync across any number of hops of either type.

> 
> I'm still seeing use cases for 101. If my H1->H2 gateway receives a WS
> Upgrade request, I'm not sure how to pass it to local servers. It can be
> worse for explicit proxies which will have to pass this to the rest of the
> world. Maybe they'll have to pass them in 1.1, or maybe some will try to
> emulate the CONNECT mode in H2, I don't know.
> 
> I remember you expressed some desire for 102, I don't know if that cannot
> be done with some informational frames later. Or maybe this is the only
> thing we'd need : send informational frames in either direction ?
> 
>> I agree that Trailers and 1xx are very similar. That being said, I'd 
>> rather get Trailer support fixed instead of them going away.
> 
> Maybe one day it will be used to transport checksums, but I doubt it given
> that I've yet to see a trailer somewhere :-/

I'm told there are a few of our Squid clients using them already. But no
confirmation of that.

> 
>> In general, while implementing HTTP/2, tons of code will need to be 
>> touched anyway; we should consider that an opportunity to also address 
>> 1.1 related bugs.
> 
> I agree on this point. I'd formulate it differently though : opportunity
> not to reproduce H1 mistakes :-)
> 
> Best regards,
> Willy
> 
>

Received on Tuesday, 15 July 2014 12:18:31 UTC