Caching Warning

Rails
1

This might be considered a bug… but I thought I’d at least warn folks.

I’m using fragment caching and the host name is in the key of the
fragment. The problem is that this is the host name used in the URL.
So, if you have two or more ways to get to the same host, you will have
multiple versions of the same cached object.

For example, if your domain is foo.com and your host is bar, then some
users might use http://bar/rest/of/path and others might use
Foo.com

In one case, bar is the host and is used in the key for the fragments
and in other cases bar.foo.com is. This creates a problem when you try
to invalid a cached entity. If you are using a sweeper and the user
comes in as bar and updates a database record, you flush the cache entry
with bar in the name but not the cache entry with bar.foo.com in the
name. You still have the old fragment cached up and some of your lusers
will hit it.

I’m not sure quiet yet how to fix this. I want to somehow modify the
host in the request to be the fully qualified hostname and not the short
hand version.

2

On Jun 9, 8:14 pm, Perry S. [email protected]
wrote:

In one case, bar is the host and is used in the key for the fragments
and in other cases bar.foo.com is. This creates a problem when you try
to invalid a cached entity. If you are using a sweeper and the user
comes in as bar and updates a database record, you flush the cache entry
with bar in the name but not the cache entry with bar.foo.com in the
name. You still have the old fragment cached up and some of your lusers
will hit it.

Sort of makes sense - you could easily have different subdomains be
different user accounts or something like that.

I’m not sure quiet yet how to fix this. I want to somehow modify the
host in the request to be the fully qualified hostname and not the short
hand version.

apache/nginx rewrite rules can do this

Fred

3

Frederick C. wrote:

apache/nginx rewrite rules can do this

I’m worried about redirects. The server is behind a firewall. The
browser thinks that foo.outside.com is different from foo. If I am
authenticated to foo.outside.com and then foo happens to ask for
authentication, the browser will ask me again instead of just sending
what it already has.

I might be worried about nothing.

4

On Jun 10, 1:45 pm, Perry S. [email protected]
wrote:

Frederick C. wrote:

apache/nginx rewrite rules can do this

I’m worried about redirects. The server is behind a firewall. The
browser thinks that foo.outside.com is different from foo. If I am
authenticated to foo.outside.com and then foo happens to ask for
authentication, the browser will ask me again instead of just sending
what it already has.

in that case it may be simpler to just fiddle the HTTP_HOST variable

Fred

5

Frederick C. wrote:

On Jun 10, 1:45�pm, Perry S. [email protected]
wrote:

Frederick C. wrote:

apache/nginx rewrite rules can do this

I’m worried about redirects. �The server is behind a firewall. �The
browser thinks that foo.outside.com is different from foo. �If I am
authenticated to foo.outside.com and then foo happens to ask for
authentication, the browser will ask me again instead of just sending
what it already has.

in that case it may be simpler to just fiddle the HTTP_HOST variable

Thats what I’m doing. Its actually a sequence of variables. I looked
at how “host” was derived when a url rewrite is done. Its the
forwarding host if set (which hit is in my case due to my apache set
up), else HTTP_HOST if set, else HTTP_SERVER if set, else …

Its working at this point.

The alternative would be to pass :host => xxx in the hash when the cache
fragments is created and deleted. That seems the safest but it hits
multiple places.