Caching in Tomcat

[Shubham Gupta <sh...@directi.com>]

Hi guys,
In order to implement infinite caching, we have put an 'Expires' & a 
'Max-Age' header to a large value, but still the browser makes a 
conditional GET for files having a relatively new 'Last-Modified' time. 
Is this a normal behaviour ?

If we remove the 'Last-Modified' & the 'Etag' header, then it always 
fetches the file from cache. Since there is no 'Last-Modified' header, 
it doesn't have an 'If-Modified-Since' header when making a condititonal 
GET (on pressing F5). Therefore, the whole file is sent back (Response: 
200 OK).

Since we noticed that for files having relatively old timestamps 
conditional GETs are being sent less frequently, we are planning to set 
the 'Last-Modified' header to a really old value (say 1970).

Does doing this have any disadvantage & is it an efficient way to 
implement infinite caching or we are missing out something here ?

-- 
/Shubham Gupta/

Re: Caching in Tomcat

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shubham,

On 6/29/2011 1:50 PM, Shubham Gupta wrote:
> In order to implement infinite caching, we have put an 'Expires' & a
> 'Max-Age' header to a large value, but still the browser makes a
> conditional GET for files having a relatively new 'Last-Modified' time.
> Is this a normal behaviour ?

I guess clients are allowed to to whatever they want. Is there anything
else going on? Intermediate proxy? SSL? Other headers at play?

> If we remove the 'Last-Modified' & the 'Etag' header, then it always
> fetches the file from cache.

What is "it"? The browser? The server? Which cache?

> Since there is no 'Last-Modified' header,
> it doesn't have an 'If-Modified-Since' header when making a conditional
> GET (on pressing F5).

What makes it a conditional GET if there is no If-Modified-Since header?

> Therefore, the whole file is sent back (Response: 200 OK).

Sounds like an unconditional GET to me.

> Since we noticed that for files having relatively old timestamps
> conditional GETs are being sent less frequently, we are planning to set
> the 'Last-Modified' header to a really old value (say 1970).

Why would you do that? If the browser is ignoring your recent
Last-Modified header, why do you think it would honor one set far into
the past? I wouldn't be surprised if browsers are "smart" enough to
detect that dates like (UNIX) zero are an error and therefore ignore
them, returning you to your unconditional GET scenario.

> Does doing this have any disadvantage

Writing hacks to lie to the client? Yes, the disadvantages are that you
have to write a lot of code (or configuration) to force something that
should be working in the first place. I suspect there is another problem
that needs to be addressed and that you are looking in the wrong place.

> is it an efficient way to implement infinite caching or we are
> missing out something here ?

Are you allowing the server to calculate an Etag header? Is the browser
sending the Etag back to the server?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4LcawACgkQ9CaO5/Lv0PBx+ACgnDokV7pVwnOphXiLcHDz7tKi
mQcAoIAiL68GCJ0VfZ/XwfX//CuL2/uq
=aX8J
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org