Hacker News Reader

Comment by mabbo | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com