Re: 103 Early Hints

On Wed, Sep 25, 2024 at 04:40:19PM -0700, Roy T. Fielding wrote:
> > On Sep 25, 2024, at 12:17 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> > 
> > On Wed, Sep 25, 2024, at 03:44, Glenn Strauss wrote:
> >> Lucas wrote:
> >> > There was also some chatter about highlighting deployment considerations about HTTP versions (i.e. it's fine for H2/3 but experience has shown that H1 can be problematic). I tend to agree with that. But I'm not sure the best sort of text to capture it, do we have any other examples of such a consideration?
> >> 
> >> There is a note in RFC8297 Security Considerations section:
> >> https://www.rfc-editor.org/rfc/rfc8297.html#section-3
> >> Lucas, is there more that you would like to add?
> > 
> > I had forgotten about that note, so thanks for the pointer! I wonder of others have forgotten too.
> 
> Are we sure that this isn't just theoretical? I have never seen a chain that claimed to be
> HTTP/1.1 and yet broke parsing arbitrary 1xx responses. I've seen one that places a limit
> on the number of 1xx responses, but that is being fixed. I've seen far more implementations
> that don't implement HEAD correctly.

FWIW HAProxy learned 1xx in 2009 (15 years ago). Previous to this, it
would consume the response, forward it and close after the non-final
response. It would pass what it received between the two sides by then
so if the client or server would use HTTP/1.1 it would be advertised as
HTTP/1.1 on the other side, but given that the response would be closed
anyway (since "Connection: close" was inserted in both directions), in
the worst case it would just be broken for the client. Needless to say
that such infrastructure compoents not supporting 1xx quickly disappeared
as 100-continue became popular as the breakage was quite visible and
frequent.

> Most recipients should ignore them. The problem cases I do see frequently are along the
> lines of "my server-to-app (or app-to-client) API hasn't provided any hooks for
> receiving 1xx response events, so they are invisible to me." That's a real problem, but
> I don't think it is our problem to solve.

In relation to this, I've found some mentions suggesting avoiding 103
with a few HTTP/1 clients. One dated 2019 mentioned that an Uptime robot
and Google's PageSpeed Insights were not expecting it by then, hence
the restriction of Early Hints to H2 only:

  https://eng.eelcowesemann.nl/2019/haproxy-early-hints/

I guess by then it's already addressed, and I agree that it's not our
problem to solve, at best we may indicate that there has been a few
mentions of incompaitible HTTP/1 clients 5 years ago.

> > The failure cases I've seen ocurred with intermediaries. Even if we tried
> > to UA sniff, there could be some proxy in the middle that is passing
> > through indicators and we can't detect it. I've also seen the opposite,
> > where an H2 proxy client spoke to an upstream CDN that emitted early hints
> > and triggered a bug in the non-final response handling of the library (that
> > bug was fixed pretty quick though and is no longer a problem). 
> 
> There are always bugs in implementations. This certainly isn't version specific.
> I would remove that text as being both inaccurate and irrelevant, since HTTP/1.1 already
> required 1xx responses to be handled in a certain way long before 103 existed. Bugs are bugs.
> Specifically, the above bug that describes a complete failure of HTTP/1.1 message parsing
> would not be fixed by avoiding use of 103. The code remains just as vulnerable to a 104.

Agreed. That's exactly what happend with haproxy in 2009 when we fixed
its handling of 1xx when it first faced it. It was an implementation bug
(more specifically a lack of implementation). Intermediaries choking on
1xx in 2024 are unlikely to be found in places where modern clients and
servers exist.

> We need to
> consider correct implementation of the protocol and how these additions might
> impact correctly-implemented current practice. Current practice that is
> already broken (violate the underlying requirements of the base protocol)
> isn't something we need to preserve. It is something we need to eradicate.
> 100, 101, and 102 have existed for a very long time. They are not new at all.
> 
> Incorrect implementations are broken. Let them be fixed. Do not introduce
> contortions in the protocol (or, worse, hamper future extensibility of the
> protocol) by making it easier for broken software to stay in the ecosystem.

+1

In addition, it's normal for a new implementation to have bugs until it
is exposed to the real world. And refraining from exposing certain classes
of components to the real world is not a good service to them as it will
postpone the detection of their breakage. Deployments of a new HTTP
implementation are expected to be very careful at the beginning and to
observe problems. Better not feed them drop by drop.

Oh and BTW I also support moving the spec out of experimental as I've
read over time that some of our users are happy with Early Hints.

Regards,
Willy

Received on Thursday, 26 September 2024 04:29:06 UTC