> HTTP 103: When the server receives a request that takes a little processing, it often can't fully send the response headers until that processing completes. HTTP 103 allows the server to immediately nudge the client to download other content in parallel, without waiting for the requested resource data to be ready.
Could someone explain why this needs a new status code at all? At the point where the new status code sends "early headers", the client was expecting the regular status code and headers anyway. Why could the server not simply do:
1) Receive request
2) Send 200 OK and early headers, but only send a single trailing newline (i.e., terminate the status line and last early header field, but don't terminate the header list as a whole)
3) Do the actual request processing, heavy lifting, etc
4) Send remaining headers, double-newline and response body, if any.
On the client side, a client could simply start to preload link headers as soon as it receives them, without waiting for the whole response.
This seems like it would lead to pretty much the same latency characteristics without needing to extend the protocol.
The only major new ability I see is to send headers before the (final) status code. But what would be the use-case for that?
Edit:
The RFC[1] sheds some light on this: The point seems to be that the headers sent in an 103 are only "canon" if they are repeated in the final response. So a server could send a link header as an early hint, then effectively say "whoops, disregard that, I changed my mind" by not sending the header again in the final response.
I still don't see a lot of ways a client could meaningfully respond to that, but I guess it could at least abort preloading to save bandwidth or purge the resource from the cache if it was already preloaded.
As with a 100, a 103 is tentative — it doesn't guarantee that the final result will be 2xx. This can happen if e.g. your web server is responsible for sending the early hints, before proxying to your app server.
Could someone explain why this needs a new status code at all? At the point where the new status code sends "early headers", the client was expecting the regular status code and headers anyway. Why could the server not simply do:
1) Receive request
2) Send 200 OK and early headers, but only send a single trailing newline (i.e., terminate the status line and last early header field, but don't terminate the header list as a whole)
3) Do the actual request processing, heavy lifting, etc
4) Send remaining headers, double-newline and response body, if any.
On the client side, a client could simply start to preload link headers as soon as it receives them, without waiting for the whole response.
This seems like it would lead to pretty much the same latency characteristics without needing to extend the protocol.
The only major new ability I see is to send headers before the (final) status code. But what would be the use-case for that?
Edit:
The RFC[1] sheds some light on this: The point seems to be that the headers sent in an 103 are only "canon" if they are repeated in the final response. So a server could send a link header as an early hint, then effectively say "whoops, disregard that, I changed my mind" by not sending the header again in the final response.
I still don't see a lot of ways a client could meaningfully respond to that, but I guess it could at least abort preloading to save bandwidth or purge the resource from the cache if it was already preloaded.
[1] https://tools.ietf.org/html/rfc8297#section-2