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.
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.
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.
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.)
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.
(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.
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".
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.
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.