Re: GWT htaccess to disable cache

On Tue, Jun 29, 2010 at 5:38 PM, Thomas Broyer <t.broyer@gmail.com> wrote:

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:

> >>>http://code.google.com/webtoolkit/doc/latest/DevGuideCompilingAndDebu...

>
> >> OK. I got it working now.
>
> > 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.
>
> 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

Isn't having a 200 after a redeploy and 304 afterwards the behavior
we're looking for?

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.

--
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-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.