Comment by potamic | Hacker News Reader

Comment by potamic | Hacker News Reader

I didn't quite understand the fundamental need behind this. While the article has explained to the extent that it will help determine who returned the cache or it will help specify who can cache, but what I don't get is why would I be interested in this?

My mental model of the internet has clients and servers. Clients will talk to servers, perhaps through intermediaries, but intermediaries are also clients and servers playing appropriate role depending on the direction of data. A server doesn't need to know where a request is coming from and a client doesn't need to know who is sending it. It's a very elegant and powerful model that allows for a great deal of flexibility.

This standard appears to treat intermediaries as a first class concern with special agency. Which means clients and servers will start handling intermediaries differently. It's a complicated and restrictive architecture overall and am not sure if it's a good idea. Was there anything fundamentally broken with the current caching mechanisms that called for this?

Client<>Proxy hop has very different characteristics than Proxy<>Server hop, so you may want to use different caching strategies for each.

For example, cache on clients for a long time, because the network is slow and expensive there, but cache on the proxy server only for a short time, so that it updates from the server relatively often.

Or you may want a reverse: cache on clients only for a few seconds, because you can't purge clients' caches. But tell the proxy to cache forever, because you will manually purge its cache when something changes.

This was previously sort-of possible with max-age vs s-maxage, but other cache directives don't have two versions. Notably, stale-while-revalidate didn't work.

Stale-while-revalidate has different implications on each hop. On the client it means it's stale until the next page load, which may be undesirable. On a proxy that keeps getting hits all the time, it's only a slight propagation delay.

> because you will manually purge its cache when something changes.

If you're talking to the proxy separately, it's no longer a proxy right? It's as good as part of your infrastructure. As long as you're able to talk to the entity directly, is there a need to allow for something like this in the standard?

I suppose this could be useful for 'public' proxies where you are able to invalidate cache with an API call, but can't create arbitrary logic for the cache

Since HTTPS everywhere happened there are no truly public proxies any more, but you often still work with reverse proxies, load balancers, WAF middleboxes, and CDNs.

A standard still helps unify things across vendors/implementations. A cacheable HTTP request is still an HTTP request, even if you use some other method to purge it later.

The architecture of the web (REST), always had intermediaries as first-class citizens. I can recommend reading into Fielding's dissertation!

The declarative and stateless message design is partly motivated by the need for intermediaries processing and understanding the messages (ie POST must not be cached f.e.).

I think the introduction explained it very well: The original design generalized too much for the needs of 2021 by putting all caches into a single bucket.

It recognized the need for intermediaries sure, but I don't believe it treated them as first class citizens. The idea has always been to treat them as proxies. Proxies extend/enhance the behaviour of a certain process without changing the interfaces. This particular standard changes those interfaces by treating proxy communication different to target communication.

The thesis: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Of cache, see eg: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...

> Layered system constraints allow intermediaries--proxies, gateways, and firewalls--to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching.

With REST (and without encryption or with trusted ssl stripping proxies) you can have a lan level cache - eg: if one of your 10 000 students access Fielding's thesis, that might be locally available for the potential 9 999 next requests. Typically this was useful for caching news site front pages - and could in theory work for video content too).

Reply on news.ycombinator.com