Could someone explain why exactly the HTTP 103 header is such a big deal?
Instead of
HTTP/1.1 103 Early Hints
Link: foo ...
Link: bar ...
<...time-consuming processing...>
HTTP/1.1 200 OK
Baz: boo
<... actual response...>
what stops you from doing
HTTP/1.1 200 OK
Link: foo ...
Link: bar ...
<...time-consuming processing...>
Baz: boo
<... actual response...>
?
The only actual new functionality I see is that you can send the "early hints" headers before having to commit to a status code for the response. Is that it?
In addition to needing to be able to change your mind about the status code (which is really important), the latter simply won't work.
Pretty much every HTTP middlebox (proxies, CDNs, etc) treats HTTP headers as a unit, buffering them up until complete (ie receiving `\r\n\r\n` in HTTP/1 and a HEADERS or CONTINUATION frame with the END_HEADERS flag set in HTTP/2). Once complete, the middlebox applies its logic based on the complete header set, and only then does it flush the headers to the client.
So if you slow-roll your headers, they'll just sit in your CDN's buffer until your time-consuming processing has finished, and only then will the browser see anything (along with the first chunk of HTML), making the whole exercise futile.
This is why the 103 is useful. A reasonable middlebox will pass the 103 along to the client as soon as the header block is complete.
I do think that most uses of the status code are either redundant (e.g. in API responses there is usually a second, much more detailed error description in the body), doesn't fit the data model (404 can mean everything from "you mistyped the service name" to "this entity does not exist", there is a retrofuturistic "payment required" code that has nothing to do with real ecommerce) or without consequence (if it's just shown in the browser)
I still don't want to argue for sending the wrong status codes like in the bad old times - it absolutely can be a problem for intermediaries - but I wouldn't have thought it to be enough of a problem to warrant its own additional protocol feature.
But I absolutely agree that, now that we have it, the 103 code is far better than any kind of hack.
I've always wished trailers were more powerful. Namely I have wished that they could contain Cookies.
It would make certain types of processing simpler and lighter being able to stream SSR bodies as they are constructed rather than all at once at the end.
You already can stream bodies as they're generated with chunked encoding; trailers aren't really needed for that.
Cookies might be useful, but I guess you could do
<script>document.cookie = '…'</script>
right before the closing `</body>` if you really needed to set cookies late in the game.
I'd love to see something to send content hashes (that browsers would actually verify), replacing the obsolete `Content-MD5`. Maybe `Integrity`, matching the `integrity` HTML attribute used in SRI? It could be a header (for static content) or trailer (for dynamic content).
Instead of
what stops you from doing ?The only actual new functionality I see is that you can send the "early hints" headers before having to commit to a status code for the response. Is that it?