Re: 103 Early Hints

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.

Just my two cents,
Willy

Received on Wednesday, 16 October 2024 03:16:12 UTC