Re: 103 Early Hints

> Am 16.10.2024 um 05:15 schrieb Willy Tarreau <w@1wt.eu>:
> 
> Hi Kazuho,
> 
> On Wed, Oct 16, 2024 at 08:17:36AM +0800, Kazuho Oku wrote:
>>> Finally, the treatment in this document on non-final responses that are
>>> not the Expect: 100-continue was unique in 2017 when 103 was forging
>>> ground. However, we now have things like resumable uploads that are using
>>> 104. Maybe there'll be some more in future. The considerations about when
>>> its safe./suitable to emit non-100 non-final responses probably applies
>>> equally to them all. So perhaps we should be thinking of extracting out the
>>> common bits into a standalone document. I appreciate that's more upfront
>>> work but might make it easier to make more robust HTTP extensions in the
>>> longer run.
>>> 
>> 
>> Yeah, assuming that the concern is about buggy HTTP/1.1 clients somewhere
>> downstream, it might make sense for intermediaries that transcode H2 or H3
>> to HTTP/1.1 to drop all advisory 1xx status codes.
>> 
>> But is that the advice we want to give?
>> 
>> As Roy argues, informational response is part of HTTP. And if we are to see
>> more applications using 1xx codes (some might need them to work, rather
>> than 103 being a pure optimization), I would be saddened if we have to work
>> on writing documents where 1xx should not be used.
> 
> I, too, think that we should consider that clients get fixed over time,
> and we must continue to push towards every implementation to respect the
> basic principles of the status code families.
> 
> Since the huge work that led to RFC7230, we've observed a massive cleanup
> of the landscape, on clients, servers and intermediaries, and with the
> arrival of languages and frameworks offering HTTP connectivity out of the
> box, combined with the amount of extensions and special cases that are not
> trivial to implement (e.g. chunked-encoding), there are less and less
> home-made implementations that result from beliefs.
> 
> Some of us remember the heated debates during WebSocket regarding the
> hypothetical support of GET+body then 101/Upgrade by then, which was going
> to break all of our implementations. Since then many were fixed and I tend
> to consider that implementations that do not support even the most basic
> HTTP/1 features (e.g. 1xx informational) are just not worth considering
> for extensions design.
> 
> Additionally there's often a good hint regarding expected support vs
> non-support: since persistent connections and chunking are difficult to
> deal with, the vast majority of self-made clients advertise HTTP/1.0 and
> not even HTTP/1.1, which is another indication that 1xx Informational
> must not be used, so I think it's reasonably safe to assumer that 1.1
> indicates proper support from the client.

+1

Cheers,
Stefan

> 
> Just my two cents,
> Willy
>

Received on Wednesday, 16 October 2024 09:17:03 UTC