Re: 103 Early Hints

> 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.

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.

> I'm not 100% sure what additional text might be good but to throw some opinions out...
> 
> The RFC text says
> 
>    Some clients might have issues handling a 103 (Early Hints) response,
>    because informational responses are rarely used in reply to requests
>    not including an Expect header field ([RFC7231], Section 5.1.1).
> 
>    In particular, an HTTP/1.1 client that mishandles an informational
>    response as a final response is likely to consider all responses to
>    the succeeding requests sent over the same connection to be part of
>    the final response.  Such behavior might constitute a cross-origin
>    information disclosure vulnerability in case the client multiplexes
>    requests to different origins onto a single persistent connection.
> 
>    Therefore, a server might refrain from sending 103 (Early Hints)
>    responses over HTTP/1.1 unless the client is known to handle
>    informational responses correctly.
> 
>    HTTP/2 clients are less likely to suffer from incorrect framing since
>    handling of the response header fields does not affect how the end of
>    the response body is determined.
> 
> 
> I think what this _might_ be overlooking is that the server might think it understands the client capabilities but that failures can happen when expectations fail. That could even happen when using HTTP/2 or HTTP/3 (although evidence suggests that HTTP/1.x client are particularly problematic for 1xx support *and* they migh trigger a security problem.
> 
> 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.

> So as I write this, I'm looking at RFC 8297 and it doesn't really have much to say about intermediaries. Section 1 states:
> 
> > The informational response can also be used by an
>    origin server to trigger HTTP/2 server push at a caching
>    intermediary.
> 
> Not sure that's something we want to include when promoting from experimental?

Nope.

> Perhaps intermediares are an area where more deployment experience could be captured, in addition to the concrete security considerations already present. 
> 
> 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.
> 
> Cheers
> Lucas

I just flat out disagree with this entire line of thought. 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.

....Roy