> 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 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.
No comments:
Post a Comment