undefined | Better HN

0 pointsnextaccountic5y ago0 comments

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.

0 comments

fiddlerwoaroof5y ago

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.

_flux5y ago

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.

majewsky5y ago

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.

1 more reply

banana_giraffe5y ago

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.

brabel5y ago

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

j / k navigate · click thread line to collapse