GWT htaccess to disable cache
Jeff Chimene
I searched the group for a GWT-specific .htaccess fragment that disables
caching for *nocache.js I couldn't find one.
Here follows a sample. I figure we can move on to something useful after
tearing it to pieces.
I'm omitting the entry for *cache* files; perhaps most HTTP servers are
already setting cache-enabling headers for those files.
=================
<FilesMatch "\.nocache\.">
FileETag None
<IfModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store,
must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</IfModule>
</FilesMatch>
=================
Thomas Broyer
On 30 juin, 00:40, Jeff Chimene <jchim...@gmail.com> wrote:
> Hi:
>
> I searched the group for a GWT-specific .htaccess fragment that disables
> caching for *nocache.js I couldn't find one.
http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html
Jeff Chimene
Right. Except that I get a 304 on the *nocache* after reloading w/ that
.htaccess fragment. What do you see?
Jeff Chimene
>
>
OK. I got it working now.
Jeff Chimene
No, I don't have it working yet. The difference seems to be that after a
compile/deploy sequence, w/o clearing the cache, w/ the .htaccess from
the docs, I see the following status sequence for the nocache
200 -> (reload) -> 304 -> (reload) -> 304...
Using the other .htaccess, I see the following status sequence for the
nocache after a compile/deploy sequence:
200 -> (reload) -> 200 -> (reload) -> 200...
IOW, does the server/browser cache management "do what I mean" when I
redeploy the app on the server? I want to get past the "please clear
your browser cache and reload" issue after deploying updates to the server.
Jeff Chimene
response headers using "ExpiresDefault "access""
0) compile
1) deploy
2) reload
response headers after first load after deploy
status: 200
----------------------------------------------
Date: Tue, 29 Jun 2010 23:59:01 GMT
Server: Apache/2.2.15 (Debian)
Last-Modified: Tue, 29 Jun 2010 23:58:32 GMT
Etag: "2e800b-105f-48a3403b57a00"
Accept-Ranges: bytes
Cache-Control: max-age=0
Expires: Tue, 29 Jun 2010 23:59:01 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1806
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/javascript
3) reload
response headers after 2nd load after deploy
status: 304
----------------------------------------------
Date: Wed, 30 Jun 2010 00:01:52 GMT
Server: Apache/2.2.15 (Debian)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=99
Etag: "2e800b-105f-48a3403b57a00"
Expires: Wed, 30 Jun 2010 00:01:52 GMT
Cache-Control: max-age=0
Vary: Accept-Encoding
===============================================
===============================================
===============================================
response headers NOT using "ExpiresDefault "access""
0) compile
1) deploy
2) reload
response headers after first load after deploy
status: 200
----------------------------------------------
Date: Wed, 30 Jun 2010 00:07:23 GMT
Server: Apache/2.2.15 (Debian)
Last-Modified: Wed, 30 Jun 2010 00:06:23 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Content-Length: 1805
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/javascript
3) reload
response headers after 2nd load after deploy
status: 200
----------------------------------------------
Date: Wed, 30 Jun 2010 00:09:12 GMT
Server: Apache/2.2.15 (Debian)
Last-Modified: Wed, 30 Jun 2010 00:06:23 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Content-Length: 1805
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/javascript
Thomas Broyer
On 30 juin, 02:15, Jeff Chimene <jchim...@gmail.com> wrote:
> On 06/29/2010 04:52 PM, Jeff Chimene wrote:
>
> > On 06/29/2010 04:33 PM, Jeff Chimene wrote:
> >> On 06/29/2010 03:54 PM, Thomas Broyer wrote:
>
> >>> On 30 juin, 00:40, Jeff Chimene <jchim...@gmail.com> wrote:
> >>>> Hi:
>
> >>>> I searched the group for a GWT-specific .htaccess fragment that disables
> >>>> caching for *nocache.js I couldn't find one.
>
> >>> Probably because it's in the doc:
we're looking for? What we want is that the browser always send a
request to the server to check if a new *.nocache.js is available, or
otherwise use the cached one (because there's no reason to download
the exact same file again). In other words, what we want is that the
browser does not *blindly* use a cached *.nocache.js, but instead
validate it against the server.
Or have I misunderstood what you're saying?
Jeff Chimene
I don't know. I must admit that I'm going by the phrase "The resource that should never be cached is the bootstrap script..." at http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebugging.html#DevGuideProdMode under the "Perfect Caching" topic.
What we want is that the browser always send a
request to the server to check if a new *.nocache.js is available, or
otherwise use the cached one (because there's no reason to download
the exact same file again). In other words, what we want is that the
browser does not *blindly* use a cached *.nocache.js, but instead
validate it against the server.
That sounds quite reasonable, and I cannot see why that wouldn't be the desired behavior. Nevertheless, why does the doc say "... never be cached..."? Because of that phrase, I cannot but feel I'm missing something important if I accept the 200 -> 304 behavior.
Or have I misunderstood what you're saying?
I don't think you misunderstand. Perhaps I'm being too didactic.
Chris Conroy
> That sounds quite reasonable, and I cannot see why that wouldn't be the
> desired behavior. Nevertheless, why does the doc say "... never be
> cached..."? Because of that phrase, I cannot but feel I'm missing something
> important if I accept the 200 -> 304 behavior.
200->304 is not only valid, it is in fact more optimal than
200->200->... While it is "cached", the cached copy is not actually
used until the 304 response comes back. So, you can be sure that you
won't be getting a stale copy, but you also won't be wasting a
transfer if the file hasn't changed between visits.
I think the confusion here comes down to the fact that cache
invalidation can affect what resources can be pulled from the disk
cache. Just because something is in the browser's cache on disk
doesn't mean that is is valid. The docs are using the term 'cached' to
mean 'on the disk and treated as valid' which is not true for the
200->304 (a.k.a a Conditional GET).
--
Chris Conroy
Software Engineer
Google, Atlanta
Jeff Chimene
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.