client_ttl?

[Sven Fuchs]

There's a client_ttl setter method in Rack::Cache::Response that is
not used anywhere else. Why's that?

http://github.com/rtomayko/rack-cache/blob/12b0de7eaa4801c97a57e6fb3c4bcf2d84056f64/lib/rack/cache/response.rb#L196

I'm not sure this is because of my unsufficient knowledge about HTTP
cache headers but I believe this is exactly what I want to use.

I want to use Rack::Cache to replace Rails page_caching in one of my
apps.

page_caching caches a response until it is purged from the cache
(disk, memcached) by the downstream app. While it the cache entry is
there the frontend server happily serves it to the client no matter
what.

Maybe I'm just returning the wrong headers but as far as I see I can
either make Rack::Cache cache the response by returning an etag or a
max-age header. When I return an etag Rack::Cache will always
revalidate with the app which is not what I want. When I return a max-
age like 999 header Rack::Cache caches the response but so does the
browser which also is not what I want.

I've played with Rack::Cache to make it to treat a cached entry as
fresh when its etag matches the requested etag. But apparently Firefox
does not send the etag after a 304 "Not Modified" response.

Thus I've figured that what I really want is allow Rack::Cache to
cache the response by giving it a really high max-age but then not
allowing the browser to cache by sending max-age=0.

Rack::Cache::Response#client_ttl= seems to do that, but it's not used
anywhere.

This seems to be doing what I want: http://gist.github.com/186264
(lines 1 and 32).

Can someone provide some inside about this? Is there another way to
achieve this behaviour?

Thanks!

[Ryan Tomayko]

On Sun, Sep 13, 2009 at 11:17 AM, Sven Fuchs <sven...@artweb-design.de> wrote:
> There's a client_ttl setter method in Rack::Cache::Response that is
> not used anywhere else. Why's that?
>
> http://github.com/rtomayko/rack-cache/blob/12b0de7eaa4801c97a57e6fb3c4bcf2d84056f64/lib/rack/cache/response.rb#L196

I believe that's dead code from when there was a whole scriptable
configuration language. The Response class was a big part of the API
you'd use in config. For instance, by matching a certain URL and
setting the client_ttl. All (or most, apparently) of that was removed
in the name of simplicity -- it wasn't used heavily.

> I'm not sure this is because of my unsufficient knowledge about HTTP
> cache headers but I believe this is exactly what I want to use.
>
> I want to use Rack::Cache to replace Rails page_caching in one of my
> apps.
>
> page_caching caches a response until it is purged from the cache
> (disk, memcached) by the downstream app. While it the cache entry is
> there the frontend server happily serves it to the client no matter
> what.
>
> Maybe I'm just returning the wrong headers but as far as I see I can
> either make Rack::Cache cache the response by returning an etag or a
> max-age header. When I return an etag Rack::Cache will always
> revalidate with the app which is not what I want. When I return a max-
> age like 999 header Rack::Cache caches the response but so does the
> browser which also is not what I want.

Sounds like you want to use s-maxage instead of max-age. It works the
same way as max-age but target shared and gateway caches and is
ignored by clients. Also, I recommend using both an expiration (with
max-age and/or s-maxage) as well as validation (with an ETag or
Last-Modified). The response will be revalidated when it's expired but
you can avoid generating the entire response again. In a lot of cases,
this makes it possible to lower the max-age/s-maxage since you won't
need to actual generate the entire response after expiration.

I'm also considering adding support for a g-maxage (for "gateway
cache") or r-maxage (for "reverse proxy cache") directive. It would
work like s-maxage but shared caches (like a Squid on your LAN) would
ignore it. There's currently no way to target the gateway cache and
not shared caches. Unfortunately, I can't find any kind of standard
here -- not even an ad hoc one.

Also, check out Things Caches Do
(http://tomayko.com/writings/things-caches-do) for more on how
expiration and validation can tag team for some really interesting
behavior.

> I've played with Rack::Cache to make it to treat a cached entry as
> fresh when its etag matches the requested etag. But apparently Firefox
> does not send the etag after a 304 "Not Modified" response.
>
> Thus I've figured that what I really want is allow Rack::Cache to
> cache the response by giving it a really high max-age but then not
> allowing the browser to cache by sending max-age=0.
>
> Rack::Cache::Response#client_ttl= seems to do that, but it's not used
> anywhere.
>
> This seems to be doing what I want: http://gist.github.com/186264
> (lines 1 and 32).
>
> Can someone provide some inside about this? Is there another way to
> achieve this behaviour?

I'm not sure why client_ttl would do what your describing here. IIRC,
it just sets the max-age directive. Are you setting it to 0 or ...?

Thanks,
Ryan