3 ms·

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

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.

banana_giraffe 6y 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.
fiddlerwoaroof 6y 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.
- _flux 6y 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.
  - majewsky 6y 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.
    - nextaccountic 6y ago
      The client should send Expect: 103-early-access in order for the server to send it. :(
brabel 6y 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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100

banana_giraffe 6y 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.

fiddlerwoaroof 6y 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.

_flux 6y 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.
- majewsky 6y 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.
  - nextaccountic 6y ago
    The client should send Expect: 103-early-access in order for the server to send it. :(

brabel 6y 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 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100