yes, incredible savings. Need to include a version number or hash tag in the URL to ensure that new versions get pushed in sync. An example: http://bbfdirect.com/
I'm working on the next level, which is enable cache-control for the HTML itself, i.e. render the page and then make AJAX calls to fetch the dynamic content, and detect out-of-date HTML using the AJAX calls. My lead eng thinks I'm psycho and I probably am. We're starting with cache-control: private on that stuff, but if I can resolve the issues with proxies serving cached data during javascript:window.reload(true), then we'll go public FTW. wish me luck (we went live with the private version yesterday), adam On Dec 7, 10:07 am, Erik <erik.e.wil...@gmail.com> wrote: > Hi Gonzo, > > If you have a lot of authenticated users the difference you are seeing > is probably in the cached authenticated requests. > > Fromhttp://www.mnot.net/cache_docs/: > > > My pages are password-protected; how do proxy caches deal with them? > > By default, pages protected with HTTP authentication are considered > > private; they will not be kept by shared caches. However, you can make > > authenticated pages public with a Cache-Control: public header; HTTP > > 1.1-compliant caches will then allow them to be cached. > > If you’d like such pages to be cacheable, but still authenticated for every > > user, combine the Cache-Control: public and no-cache headers. This tells > > the cache that it must submit the new client’s authentication information > > to the origin server before releasing the representation from the cache. > > This would look like: > > Cache-Control: public, no-cache > > Whether or not this is done, it’s best to minimize use of authentication; > > for example, if your images are not sensitive, put them in a separate > > directory and configure your server not to force authentication for it. > > That way, those images will be naturally cacheable. > > On Dec 6, 4:19 pm, GONZO <gonzom...@gmail.com> wrote: > > > > > > > > > Hi, first thanks for your attention and sorry for my English > > translation. > > > I have a question that intrigues me a few weeks. This is the header > > "cache-control" in particular the behavior of the options "private" > > and "public" in Google App Engine. > > > First of all, this is only to serve static files (css, js, etc) > > > Let's go. With "cache-control: private" experiment curve normal > > traffic. But with "cache-control: public" experiment Traffic > > incredible savings. In both cases, everything seems to work well. > > > The question is: > > > 1. How can traffic be a big savings? Is reduced to 15%. > > > 2. Saving you a real traffic? Or is something special instead of > > Google App Engine? > > > Better look at this diagram > > illustrates:http://gonzo.teoriza.com/almacen/cache-control.jpg > > > Thanks in advance, I hope to be clarified. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appeng...@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
