Hacker News Reader

Comment by xg15 | Hacker News Reader

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?

View on HN

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.

Thanks for the explanation! Yeah, if this is a known limitation of existing intermediaries, it makes a lot of sense.

I think you answered your own question! What if the processing times out and you need to send a 4xx code?

Good point!

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.

Reply on news.ycombinator.com