[nextaccountic]

Do you mean that the same HTTP/1.1 GET request can have two different headers with two different status code?

What's the reported status code of this response in typical libraries? Usually the status code is a single value and not a list.

[fiddlerwoaroof]

10x status codes are already used for multipart requests and responses, right? 100 Continue and the like. This is usually handled transparently by your client library.

[_flux]

I'm going to assume many HTTP libraries and ad-hoc implementations expect one HTTP response for one HTTP request (but still support pipelining) and will break if this underlying assumption changes.

In fact, this may even be ratified in the interfaces they provide: think synchronous "give contents of this URL" functions.

[majewsky]

That's the most significant criticism of RFC 8297 (the 103 Early Hints response) from my cursory reading of the RFC. It should only be allowed when the client indicates that it can process 1xx responses. All other 1xx responses are like that AFAIK, e.g. 100 Continue is only sent when the client sets the "Expect: 100-continue" header. So a client that doesn't do that doesn't need to care about 100 Continue responses.

[nextaccountic]

The client should send Expect: 103-early-access in order for the server to send it. :(

[banana_giraffe]

Yep, two (or more, the spec allows for multiple 103 responses before the "real" response) responses returned from one request.

The one library I threw a test server at didn't respond well. It treated the 103 as the response, and the actual 200 as the body. It was an older library, and the spec suggests using client sniffing to pick which clients to send 103 to. That's kinda when I stopped trying to figure it out, I'm not surprised to learn no one really implements it.

[brabel]

Yes, that's how 100-Continue works and it is widely implemented (but mostly this is hidden by application libraries):

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100