On Tue, Jun 29, 2010 at 5:38 PM, Thomas Broyer <[email protected]> wrote:
> > > On 30 juin, 02:15, Jeff Chimene <[email protected]> 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 <[email protected]> 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#DevGuideProdModeunder 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
