Hacker News Reader

Comment by richdougherty | Hacker News Reader

Summary: a new status code that lets the server send headers early, before the main headers. This helps with optimisations like preloading. Example from the document:

     HTTP/1.1 103 Early Hints
     Link: </main.css>; rel=preload; as=style

     HTTP/1.1 103 Early Hints
     Link: </style.css>; rel=preload; as=style
     Link: </script.js>; rel=preload; as=script

     HTTP/1.1 200 OK
     Date: Fri, 26 May 2017 10:02:11 GMT
     Content-Length: 1234
     Content-Type: text/html; charset=utf-8
     Link: </main.css>; rel=preload; as=style
     Link: </newstyle.css>; rel=preload; as=style
     Link: </script.js>; rel=preload; as=script

The client can start preloading the CSS and JavaScript before the main headers arrive. This is a nice optimisation.

There are various security risks with sending multiple headers to non-conforming clients hence: "Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly."

View on HN

Trying to wrap my head around this.

The server is going to be slowly building up a real reply. But it also knows that most likely, the real reply is going to need a list of assets that doesn't change regardless of what the reply is.

So to save time, the server is going to spit out a few packets early that say "Hey, while you're waiting on me, go load these".

Am I understanding this right?

It's like your server at the restaurant bringing you appetizers early because they're fast to cook and you were just going to be sitting there doing nothing anyways.

Generally correct. However, the the final response won’t necessarily actually include those headers, so it’s more that the server is saying, “I think you’ll get this, but don’t quote me on it”.

In the case of a Link header, it would thus be OK to fetch the resources, and if you don’t end up needing them, c’est la vie. In the case of CSS, it’d be perfectly legitimate to load the CSS in anticipation. It would even be OK to execute JavaScript up to the point of its needing to interact with the document or HTTP. But it would be not OK to execute anything that was not safe (in the terminology of the HTTP spec on methods).

I’d extend your parallel in appetisers, but it gets mildly disturbing quite quickly.

So like the server bringing you a glass of water and basket of bread that you may or may not want, but most people do so the odds are good enough.

the parent was implying that the server might later change their mind and ask for the water and bread back, so you shouldn't do anything irreversible with it.

In the interest of clobbering the analogy even further: It would be like the server bringing you a red wine and then serving fish - the red wine doesn't go with it, so you better hope you can get it off the table and the taste out of your mouth.

OK, since we are into analogies:

A recipe with a shopping list. Only you get the shopping list first and some of the items might be for another recipe (and you might already have them.)

It's your teacher giving you a list of books to check out at the library that you may or may not need for this semester.

It's like rain on your wedding day?

i.e. only idempotent operations, such as GET. You should not perform a POST using the information obtained in these hints.

Perhaps an alternative analogy is branch prediction? Browser is permitted to run along a particular path of execution because it applies in most cases. But you end up throwing away your work in the case that the prediction turns out to be wrong.

In terms of practical application for this - most modern sites run their content over an additional layer of application logic that runs in the browser e.g. React, or Angular or something. These hints can tell the browser that such-and-such an application framework is required to display the content, and to go get it before the content is available.

No, not idempotent operations; safe operations. When speaking of HTTP methods, PUT and DELETE are both idempotent but not safe; you wouldn’t the user agent to DELETE a resource based on merely a hint—it needs to wait until the actual response comes in, at which point it can confirm whether the header is there and to be acted upon.

See https://tools.ietf.org/html/rfc7231#section-4.2 for the definitions.

(Keep in mind with 103’s semantics that we’re not talking about HTTP methods, we’re merely borrowing its definition of “safe”. Speculative JavaScript execution, for example, is perfectly feasible; you’d simply have to pause execution as soon as it tried to mutate its environment or make HTTP requests or things like that. How useful it is is another question.)

I took idempotent and safe to be functionally equivalent. i.e. that which causes no state-change on the server. Thanks for the correction. Effectively a "debounced" operation.

Idempotent just means that you can do it as many times as you want (n) and the state will remain the same, for n >= 1.

The origin of my confusion is the definition of GET as idempotent. My understanding of this verb is it (should) cause no mutations. So the correct classification of GET is "safe".

Safe is a subset of idempotent.

Idempotent means that one invocation has the same effect as more than one invocation.

Safe means that zero invocations has the same effect as one or more invocations.

Yeah I understand how the categories work but the language was heretofire confusing

I'd rather say: It's like the default set if knife/fork/spoon set out at the table. They might be taken away or replaced based on what you actually end up ordering. But for the most part they will work out.

Some of the restaurants I go to, the analogy might still apply. "We didn't order garlic bread, but hey why not?"

Importantly, the server serving up the main page may not be the same one serving up static assets. You hit the main page and it sends back 103s telling your browser to then download a bunch of stuff off of a CDN ASAP even while the main page is still being transferred.

No! It's your pizza delivery service sending you menu of appetizers, because pizza is not ready yet. Oh! BTW you might not get this menu incase of traffic jam (aka buffering proxies), and pizza might arrive with menu as well :D.

So is there a default header to say 'I support 103s' or 'here are my extended capabilities'? Or are we just going to have every API ask for 'x-<company>-preload: true'?

From [1]:

"A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses."

They don't need to be requested. Supporting servers will just send them, unsupporting clients will just ignore them (barring the potential security issue with broken HTTP/1.1 implementations which is noted in the 103 spec).

[1] https://tools.ietf.org/html/rfc7231#section-6.2

For HTTP 100, there is the Expect: header to indicate capability. I think it would make sense to use it here as well.

Sounds a lot like HTTP/2 push.

From the RFC intro:

> HTTP/2 ([RFC7540]) server push can accelerate the delivery of resources, but only resources for which the server is authoritative. The other limitation of server push is that the response will be transmitted regardless of whether the client has the response cached. At the cost of spending one extra round-trip compared to server push in the worst case, delivering Link header fields in a timely fashion is more flexible and might consume less bandwidth.

There are cache-aware HTTP2 server push technologies that can be used to cut that down wasted bandwidth.

See: https://h2o.examp1e.net/configure/http2_directives.html#http...

Although HTTP/2 PUSH_PROMISE is a lot more complicated for developers: https://jakearchibald.com/2017/h2-push-tougher-than-i-though...

Just saying: you'd need to have the socket with tcp_nodelay for this to actually work.

This in general is a terrible idea IMHO

I use tabix.ui for Clickhouse, clickhouse generates tons of extra headers as progress bars. Chrome will just cut the connection and says header too large error.

http 103 will just be abused like that. People will make megabytes sized headers

Not likely. Megabyte sized headers would significantly degrade the loading performance of the web site since the browser can't go on to begin fetching the main content until the headers have arrived. So, operators that don't care for performance might abuse it, but then why would they bother at all?

Wouldn't that same logic mean that we can't have JavaScript, CSS, image/audio/video, etc. because some people will send too much junk? We can't prevent people from using the web badly but anyone who doesn't completely disregard the user experience will be subject to the usual feedback loop.

Reply on news.ycombinator.com