Thanks for the clarification.
On Tue, Jun 29, 2010 at 8:16 PM, Chris Conroy <[email protected]> wrote: > On Tue, Jun 29, 2010 at 10:36 PM, Jeff Chimene <[email protected]> wrote: > > > 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 > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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.
