Hacker News Reader

Comment by nimrody | Hacker News Reader

> There are still requests sent, there is still network latency. [In the case of small JS/css/icon files, the latency can be as much as the transfer time].

What? When the "Expires" header indicates the item is still valid the browser should use the cached object without making any requests.

Some servers (Rails for example) just serve assets with "Expires" set to some distant future time. When they want to expire these files, they simply change the name (hence the long numeric suffix appended to js/css/etc. files)

View on HN

This "always revalidate" behavior only happens on refresh.

Normal navigation does not trigger it.

Yeah, I was wondering why I bother to set the expires header if the browser is going to ignore it and check every time anyway.

To give a hint to the cache manager about when to remove the file from its storage ;)

It doesnt ignore it. In chrome, if you keep the network tab in dev tools open, you will see "From disk/memory cache" in the size column with a status of 200 when it comes from local cache.

It ignores it on refresh before the page load event. It respects it otherwise.

> the browser should use the cached object without making any requests.

That's a common (mis)assumption, but that's not how it works in practise. Sorry ^^

I cannot comment on what was the intended behavior when HTTP caching and headers were first designed, a very long time ago.

It seems to me, that is was "request everytime + get 304 if not modified, thus save the file transfer time". That's how most implementations work in my experience.

Historically, transfer duration was way more problematic than latency. It's only recently that there are pages with hundreds of dependencies.

---

Rails and webservers: They MUST change the filename or the application will be fucked because of caching issues, mostly because of Firefox :D

All major browsers do respect the TTL if one is set. So it does save many requests. If it's not possible to the the TTL because the content might change at any time it is still useful to a caching header with a TTL of 0. Otherwise the browser will perform heuristic caching and compute a (often imprecise) estimation based on the last-modified header.

> but that's not how it works in practise

As someone who has actually worked on a browser's network stack, I can assure that it _is_ how it works in practice.

Reply on news.ycombinator.com