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? 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? -- 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.
