Hi Ikai So does that mean that the google front proxies do not honour Etags in the headers as produced by the google supplied static handler.?
You said " > On the flip side - you should also not assume that a deploy will invalid > the cache, as the edge cache has no knowledge of your code being updated. > " I was under the impression that the purpose of Etag's, was so that upstream/edge caches could be invalidated. Whilst I see cache busting working for js and css files, it would seem to be a lot more difficult to manage cache busting for images. (Thankfully they tend to change less frequently) Thanks for looking at this Rgds Tim On Jun 5, 8:31 am, "Ikai L (Google)" <[email protected]> wrote: > Hey guys, > > I've tracked this down, and it is working as intended. Our infrastructure > may or may not respect your cache headers and just cache assets for your > application. It's clear that's what's happening here, with some front-ends > caching and some not caching. The worst case scenario is that cache headers > are not respected; the best case scenario is that all requests are served > from an edge cache. Most developers will fall somewhere in between. If a > cache header is set, you should not assume that the edge cache will expire > it. On the flip side - you should also not assume that a deploy will invalid > the cache, as the edge cache has no knowledge of your code being updated. > > In general, use of a cache-buster for static assets is an absolute must in > web development for all the reasons I mentioned in a previous post: ISP, > reverse proxy caching, desktop accelerators, weird browser caching, etc. > I'll make it a point to make the documentation about our edge caching > infrastructure more clear about this and include examples on how to > correctly include media, stylesheets and Javascript includes. > > > > On Fri, Jun 4, 2010 at 4:47 PM, Tim Hoffman <[email protected]> wrote: > > Hi Ikai > > > So here is the route to the domain mapped app > > > traceroute towww.polytechnic.wa.edu.au(72.14.203.121), 30 hops max, > > 60 byte packets > > 1 dlink.dir451 (192.168.1.254) 1.390 ms 2.382 ms 9.842 ms > > 2 * * * > > 3 * * * > > 4 * * * > > 5 vlan511.o6ssc76fe.optus.net.au (59.154.14.125) 957.339 ms > > 958.177 ms * > > 6 * gi9-6.pstmadist02.aapt.net.au (202.10.13.102) 950.008 ms > > 951.868 ms > > 7 66.249.95.234 (66.249.95.234) 968.417 ms 329.715 ms 348.896 ms > > 8 209.85.249.52 (209.85.249.52) 447.684 ms > > te0-3-1-0.pgroscore01.aapt.net.au (202.10.12.33) 358.795 ms 343.266 > > ms > > 9 209.85.250.90 (209.85.250.90) 300.117 ms 299.892 ms > > gi0-0-0-1.mflincore01.aapt.net.au (202.10.10.84) 156.907 ms > > 10 209.85.250.103 (209.85.250.103) 315.736 ms 289.746 ms 300.058 > > ms > > 11 te2-2.sclardist02.aapt.net.au (202.10.12.4) 149.830 ms 149.851 > > ms 209.85.241.154 (209.85.241.154) 289.833 ms > > 12 te3-1.sclarbrdr01.aapt.net.au (202.10.14.5) 159.967 ms tx-in- > > f121.1e100.net (72.14.203.121) 319.701 ms 300.186 ms > > t...@chrome:~/qtrack$ > > > Directly to the appspot app > > > t...@chrome:~/qtrack$ traceroute psc-prod1.appspot.com > > traceroute to psc-prod1.appspot.com (66.102.11.141), 30 hops max, 60 > > byte packets > > 1 dlink.dir451 (192.168.1.254) 1.181 ms 2.085 ms 2.573 ms > > 2 * * * > > 3 * * * > > 4 * * * > > 5 * * * > > 6 * google.sd13.optus.net.au (119.225.36.2) 410.318 ms 409.141 ms > > 7 * 66.249.95.232 (66.249.95.232) 760.075 ms * > > 8 te0-3-1-0.pgroscore01.aapt.net.au (202.10.12.33) 636.765 ms > > 133.826 ms 158.857 ms > > 9 gi0-0-0-1.mflincore01.aapt.net.au (202.10.10.84) 199.897 ms > > syd01s01-in-f141.1e100.net (66.102.11.141) 169.789 ms 159.778 ms > > > And to ghs.google.com looks the same as the first as I would expect. > > > Rgds > > > T > > > On Jun 5, 6:23 am, "Ikai L (Google)" <[email protected]> wrote: > > > Can you guys run a traceroute on your domains vs. the appspot domain? > > > > E.g: > > > > traceroute qa.connectscholar.com > > > traceroute charityaxis-qa.appspot.com > > > > If you're on Windows, the equivalent command is "tracert". > > > > I'm curious if there's an ISP or specific Google Frontend that is acting > > up. > > > > On Thu, Jun 3, 2010 at 2:02 PM, Ikai L (Google) <[email protected]> > > wrote: > > > > > You should still be billed for bandwidth. The advantage of using edge > > > > caching is that if the resource is being served from the datastore or > > > > dynamically generated via some other means, you will not incur CPU > > costs. > > > > > On Thu, Jun 3, 2010 at 12:55 PM, Ross M Karchner < > > [email protected]>wrote: > > > > >> Partially off-topic--- if GFE serves a cached resource, do we get > > billed > > > >> for the bandwidth? > > > > >> On Wed, Jun 2, 2010 at 3:27 PM, Ikai L (Google) <[email protected] > > >wrote: > > > > >>> Okay, looks like the Google Front-End is kicking in to cache your > > stuff > > > > >>> Server Google Frontend > > > >>> Content-Length 2834 > > > >>> Age 41 > > > >>> Cache-Control public, max-age=600 > > > > >>> Are you guys setting this header anywhere? Unfortunately, there's no > > way > > > >>> to invalidate items in the frontend cache, so you'll have to use a > > cache > > > >>> buster or wait for the TTL to expire. > > > > >>> On Wed, Jun 2, 2010 at 12:22 PM, J <[email protected]> wrote: > > > > >>>> That's interesting, Rafael. I wonder why it serves correctly for > > you. > > > > >>>> They are still different from my PoV. > > > > >>>> The bad side headers: > > > >>>> Etag "74EQOA" > > > >>>> Date Tue, 01 Jun 2010 18:12:57 GMT > > > >>>> Expires Sat, 05 Jun 2010 02:12:57 GMT > > > >>>> Content-Type text/css > > > >>>> Content-Encoding gzip > > > >>>> Server Google Frontend > > > >>>> Content-Length 2820 > > > >>>> Cache-Control public, max-age=288000 > > > >>>> Age 90134 > > > >>>> X-XSS-Protection 0 > > > > >>>> The good side headers: > > > >>>> Etag "7xGL5w" > > > >>>> Date Wed, 02 Jun 2010 19:13:00 GMT > > > >>>> Expires Wed, 02 Jun 2010 19:12:04 GMT > > > >>>> Content-Type text/css > > > >>>> Content-Encoding gzip > > > >>>> Server Google Frontend > > > >>>> Content-Length 2834 > > > >>>> Age 41 > > > >>>> Cache-Control public, max-age=600 > > > > >>>> Short of using a cache-buster, is there a setting I can use on GAE > > or > > > >>>> in my app.yaml file? > > > > >>>> On Jun 2, 3:01 pm, "Ikai L (Google)" <[email protected]> wrote: > > > >>>> > I wonder if there is some layer of the infrastructure that is > > > >>>> performing > > > >>>> > caching without you guys having opted-in, hence the reason why a > > > >>>> > cache-buster like ?v=something works. Can you guys confirm? Also - > > are > > > >>>> you > > > >>>> > guys setting any headers? Which headers get returned? > > > > >>>> > I've personally always used cache busters for the simple reason > > that > > > >>>> > sometimes users using web-accelerators or with aggressive ISP or > > > >>>> caching > > > >>>> > settings tend to key off the URL. Can you guys use this workaround > > in > > > >>>> the > > > >>>> > meantime? > > > > >>>> > On Wed, Jun 2, 2010 at 11:57 AM, Rafael Sierra < > > [email protected] > > > >>>> >wrote: > > > > >>>> > > On Wed, Jun 2, 2010 at 3:37 PM, J <[email protected]> > > wrote: > > > >>>> > > > To reproduce the problem, go to > > > >>>> > >http://qa.connectscholar.com/stylesheets/caSkin.css > > > >>>> > > > and also tohttp:// > > > >>>> charityaxis-qa.appspot.com/stylesheets/caSkin.css. > > > >>>> > > > Both URLs point to the same file but one returns the old > > content > > > >>>> and > > > >>>> > > > appspot.com returns the new content. > > > > >>>> > > Same file here: > > > > >>>> > > Hidan:~ sdm$ curlhttp:// > > > >>>> charityaxis-qa.appspot.com/stylesheets/caSkin.css> 1 > > > >>>> > > % Total % Received % Xferd Average Speed Time Time > > > >>>> Time > > > >>>> > > Current > > > >>>> > > Dload Upload Total Spent > > > >>>> Left > > > >>>> > > Speed > > > >>>> > > 100 10941 0 10941 0 0 6146 0 --:--:-- 0:00:01 > > > >>>> --:--:-- > > > >>>> > > 31918 > > > >>>> > > Hidan:~ sdm$ curlhttp:// > > > >>>> qa.connectscholar.com/stylesheets/caSkin.css> 2 > > > >>>> > > % Total % Received % Xferd Average Speed Time Time > > > >>>> Time > > > >>>> > > Current > > > >>>> > > Dload Upload Total Spent > > > >>>> Left > > > >>>> > > Speed > > > >>>> > > 100 10941 0 10941 0 0 2777 0 --:--:-- 0:00:03 > > > >>>> --:--:-- > > > >>>> > > 3854 > > > >>>> > > Hidan:~ sdm$ md5 1 > > > >>>> > > MD5 (1) = 8f5ef511be1a03fd722223337c334933 > > > >>>> > > Hidan:~ sdm$ md5 2 > > > >>>> > > MD5 (2) = 8f5ef511be1a03fd722223337c334933 > > > > >>>> > > > On Jun 2, 1:18 pm, "Ikai L (Google)" <[email protected]> > > wrote: > > > >>>> > > >> Thanks for bringing this up, Tim. Anyone else seeing this > > > >>>> problem? If > > > >>>> > > so, > > > >>>> > > >> please post details. Are you guys setting any kind of cache > > > >>>> headers? > > > > >>>> > > >> I'm going to try to reproduce these issues, so any > > information > > > >>>> will be > > > >>>> > > >> helpful. > > > > >>>> > > >> On Wed, Jun 2, 2010 at 9:14 AM, J <[email protected]> > > > >>>> wrote: > > > >>>> > > >> > Thanks, Tim, for letting me know I'm not going insane. > > > > >>>> > > >> > To the Google guys, this problem seems to have started > > > >>>> yesterday > > > >>>> > > >> > afternoon (1:30-ish PM, EDT) in case it helps you track > > down > > > >>>> the > > > >>>> > > >> > cause. > > > > >>>> > > >> > On Jun 2, 8:19 am, Tim Hoffman <[email protected]> wrote: > > > >>>> > > >> > > Hi > > > > >>>> > > >> > > We have been trying to deploy a major revision of one of > > our > > > >>>> apps. > > > > >>>> > > >> > > Under the specific version 2-0-0.latest... all the new > > > >>>> css/js and > > > >>>> > > >> > > static images are available. > > > > >>>> > > >> > > When we make the new version default, the css, js and > > static > > > >>>> files > > > >>>> > > are > > > >>>> > > >> > > accessible via <appid>.appspot.com > > > > >>>> > > >> > > However when accessing the same site via the google apps > > > >>>> domain > > > >>>> > > >> > > mapping we are still > > > >>>> > > >> > > getting the old versions css, js and static images. > > > > >>>> > > >> > > I have tried removing the apps domain mapping and > > re-adding > > > >>>> it with > > > >>>> > > no > > > >>>> > > >> > > affect. > > > > >>>> > > >> > > We have had to revert to the earlier version as all > > access to > > > >>>> the > > > >>>> > > site > > > >>>> > > >> > > is via the apps domain and > > > >>>> > > >> > > its not working with the latest version missing the new > > > >>>> css/js. > > > > >>>> > > >> > > has anyone got any ideas on how we can address this. > > > > >>>> > > >> > > I know absolutely that the problem is not a browser > > cache, as > > > >>>> I have > > > >>>> > > >> > > been > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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-appengine?hl=en.
