KenjiBaheux / resource-freshness

Proposal for a HTTP header field to be used in the context of stale-while-revalidate (RFC5861)
Apache License 2.0
5 stars 1 forks source link

Caching proxies #1

Open ricea opened 10 years ago

ricea commented 10 years ago

I think proxies should not modify or alter the Resource-Freshness header.

My reasoning is that the main goal of this header is to permit servers to optimise the user experience. We want to know when the browser was able to re-use the resource without having to make a synchronous network request, because that translates to a seamless user experience.

If a intermediary cache was able to use stale-while-revalidate to serve a response to the browser faster, that is good, but in most cases will not provide the same quality of experience as when the browser was able to use it.

If caches did modify Resource-Freshness, then when calculating statistics to determine the end-user benefit of stale-while-revalidate servers would have to ignore requests that came via proxy servers. In most cases proxy servers identify themselves by adding "Via" headers, but not always. This would tend to add a statistical bias, particularly under-counting corporate and mobile users who are typically behind proxies.

The disadvantage is that the value of the Resource-Freshness header may not be consistent with other caching-related request headers that are modified by caching proxies, particularly If-Modified-Since. I think this is acceptable.

igrigorik commented 10 years ago

/cc @mnot