Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
Caching is a best effort attempt to reduce load and should never be thought of as a foolproof mechanism to prevent requests from hitting your server. In the case you are describing, URL parameters still work since they prevent the proxies and browsers from storing things they shouldn't store. Most proxies and browsers key off URL, including any request parameters. I have personally never seen browsers or proxies that will not cache a URL with parameters, but I believe they may exist. It's not the worst thing in the world if your assets are not cached - in some cases it is 100x worse to serve a stale asset, especially if your app is JavaScript heavy. In any case, URL rewriting is a pretty good technique as well, I just don't think it's fair to call appending a query parameter problematic, as I feel it is is an overall easier approach than URL rewriting. In either case, they both encourage the best practice of creating methods in templating language to rewrite image, media and JS tags. For instance, in JSPs, you could have something like the following to output tags: %= AssetTag.imageUrl(someImage.jpg) % (I should write a blog post or something about this subject.) On Mon, Jun 21, 2010 at 12:41 AM, TL twl.e...@gmail.com wrote: On Jun 15, 4:36 pm, Ikai L (Google) ika...@google.com wrote: What are the other problems? The major problem is that browsers and proxy servers may not cache any URL that has request parameter, regardless of caching headers returned by the response (such as max-age). This is up to the proxies and user agents which have varying policies. On the other hand, using simple resource name with no parameters, does not exhibit such behaviors. -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
Ah, interesting argument. I've never personally been in a situation where we've had to replace CSS referenced images enough times that manually changing their URIs was a problem, even in environments where I was deploying 5+ times a day. In practice, every time I've used CSS referenced images, they've been because of backgrounds (rare changes), rounded corner hacks or other browser hacks that don't change enough. I think you may have sold me, and at the very least I shouldn't knock it until I try it. Anything to kill those nasty cache issues that pop up. Moral of the story: always use a cache buster. On Mon, Jun 21, 2010 at 1:13 PM, TL twl.e...@gmail.com wrote: Here is another problem with query parameters: You have a CSS file with background URL background:url(group/google-appengine/icon?hl=en); You call the CSS file with cache buster parameter: http://example.com/static/base.css?timestamp=12345678 The CSS file will call the image /group/google-appengine/icon?hl=en without the cache buster. Unless you want to change your CSS files manually every time you replace an image or do it in a build using some script, you cannot version an image that you use from CSS. On the other hand, if you name the CSS file: http://example.com/static/123456/css/base.css and make the URLs relative in CSS: background:url(../group/google-appengine/icon?hl=en); Then the browser will call the URL: http://example.com/static/123456/ group/google-appengine/icon?hl=en Every time you change a version number, it affects ALL your static files in one shot, with zero work for you. Including images from CSS, and many other things that can be done relative. I agree that caching is not something that works accurately and predictably, but you can still make it more effective by avoiding known problems. If you are into rapid development, where you release almost every day, then the advantage of zero work system for versioning static files is invaluable. You never have to mess with it, just increase the version number and all static files get upgraded in one shot. -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
The tradeoff with request parameters is that you need to output your image and asset tags in your HTML templates to append a parameter and be version aware. The benefit, however, is that it is an almost 100% foolproof way to bust caches. You don't only have the Google edge cache to worry about - you've always got to worry about ISP proxies, browser caches + other caching schemes that users introduce between their computers and your application. I highly recommend doing this, as you will spend countless hours debugging user issues (I have) that are cache related that could be easily solved by appending a URL parameter. This is especially true if you use any kind of JavaScript code that changes. What are the other problems? On Tue, Jun 15, 2010 at 1:13 PM, TL twl.e...@gmail.com wrote: That is really the only solid way to do it. Using request parameter has too many problems to list. I did this in a Java app and it does require you to write some code, since as you mention Java does not have a built in rewrite capability. I may add google code project with a Java implementation for app engine (using the app engine version as a directory). Will keep you posted. E On Jun 3, 12:35 pm, Donovan donovan.jime...@gmail.com wrote: Another technique for cache busting is URL rewriting within the path to the resources, which has some benefits over the query string usage in certain cases. The Python AE runtime supports URL mapping for static resources which can make this even less painful and allows long expire times - so for example you could generate all static URLs like this: /static/[app version from environment]/css/foo.css and have it map to the static/your/foo.css withint your appengine upload This has an advantage in the case of css because then all your resources referenced from the CSS (as long as they're using relative URLs under the same static directory) are also affected by the path versionion. So a background-image: url(../images/bar.jpeg) ; declaration in the foo.css above would cause the browser to request the resource with the injected app version /static/[app version]/ images/bar.jpeg. This would not happen with the query string cache busting technique unless you willing to parse your css dynamically (and then you're not using the static file appengine servers). Using this technique you can feel free to set your static file caching headers to large values (months to a year) to get a better client experience without sacrificing the ability to update your app at will (your app version id will change everytime you upload, which creates a new URL and new set of cacheable objects to the browser) Unfortunately, the Java AE runtime does not have a similar support for static file URL rewriting - I've done a feature request here (PLEASE STAR! :) )http://code.google.com/p/googleappengine/issues/detail?id=2070 So, to get the same behavior and peformance benefit of hitting the AE static file servers, you'd have to physically create a versioned directory during the build process before uploading to appengine . You could do the same thing for the python as well, but the URL mapping feature is so easy to use I've never wanted to do so. - Donovan -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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) ika...@google.com 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 rosskarch...@gmail.comwrote: 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) ika...@google.comwrote: 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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp:// qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem) - issue raised
This probably is still occurring. Just out of curiosity - is your ISP Comcast? On Fri, Jun 4, 2010 at 4:56 AM, J j.si...@earlystageit.com wrote: A couple of closing-out notes from our vantage point in Massachusetts. First, even though the cache for one of our files was not supposed to expire until June 5, it was serving the correct content as of late June 3. Whether it was an ISP issue or a GFE issue, we will never know. Second, we have deployed the technique recommended by Donovan and hope to never see this problem again. Finally, a bouquet of virtual flowers for Ikai. Thanks for jumping on the problem and helping us put a solution in place. On Jun 3, 7:43 pm, Tim Hoffman zutes...@gmail.com wrote: Hi Ikae We couldn't leave the production environment in place with the broken urls. So have already deployed a version with args on the end of all css/js urls. I don't believe it was an ISP issue. We tried accessing the site from 5 different ISP's in Australia when we first discovered the problem. Maybe you behind googles infrastructure can't see the issue. More than a few people have posted links exhibiting the problem in the list (and they aren't in Australia). We have a full test instance in gae as well but we haven't been mapping it do a domain to date. As we have never experienced this issue before. (Site went live mid last yearwww.polytechnic.wa.edu.au) Rgds T On Jun 4, 1:49 am, Ikai L (Google) ika...@google.com wrote: Tim, can you provide 2 URLs that are doing this? I'm still trying to reproduce the problem. Could an ISP be caching these files? On Thu, Jun 3, 2010 at 10:02 AM, Tim Hoffman zutes...@gmail.com wrote: Hi Not to bad an idea. At the moment all of our templates use '/css/some_file.css' rather than including hosts. So we don't need to make changes between code bases or have to lookup what the host should be, (in light of the issue we may well have to change that strategy) For the moment we just add ?some value to the end of the css/js files that are changing, and will probably set up a script to be run prior to appcfg, to increment these values. All the css/js is referenced in just a couple of main templates (zpt) Rgds T On Jun 3, 10:17 pm, J j.si...@earlystageit.com wrote: Tim, what we ended up doing was a bit different. We have qa.abc.com pointing to xyz-qa.appspot.com. We did not change file names as was recommended -- that would be a pain in the rear to manage. But we took advantage of the fact that xyz- qa.appspot.com delivers content correctly. We changed references to / scripts/pqr.js tohttp://xyz-qa/appspot.com/scripts/pqr.js. It was faster to put in place and it buys us some time until we can come up with something better. Hope that helps. On Jun 2, 7:44 pm, Tim Hoffman zutes...@gmail.com wrote: Hi I have raised an issue for this http://code.google.com/p/googleappengine/issues/detail?id=3297 Rgds T -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.comgoogle-appengine%2Bunsubscrib e...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog:http://googleappengine.blogspot.com Twitter:http://twitter.com/app_engine Reddit:http://www.reddit.com/r/appengine -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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 zutes...@gmail.com wrote: Hi Ikai So here is the route to the domain mapped app traceroute to www.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) ika...@google.com 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) ika...@google.com 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 rosskarch...@gmail.comwrote: 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) ika...@google.com 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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem) - issue raised
Tim, can you provide 2 URLs that are doing this? I'm still trying to reproduce the problem. Could an ISP be caching these files? On Thu, Jun 3, 2010 at 10:02 AM, Tim Hoffman zutes...@gmail.com wrote: Hi Not to bad an idea. At the moment all of our templates use '/css/some_file.css' rather than including hosts. So we don't need to make changes between code bases or have to lookup what the host should be, (in light of the issue we may well have to change that strategy) For the moment we just add ?some value to the end of the css/js files that are changing, and will probably set up a script to be run prior to appcfg, to increment these values. All the css/js is referenced in just a couple of main templates (zpt) Rgds T On Jun 3, 10:17 pm, J j.si...@earlystageit.com wrote: Tim, what we ended up doing was a bit different. We have qa.abc.com pointing to xyz-qa.appspot.com. We did not change file names as was recommended -- that would be a pain in the rear to manage. But we took advantage of the fact that xyz- qa.appspot.com delivers content correctly. We changed references to / scripts/pqr.js tohttp://xyz-qa/appspot.com/scripts/pqr.js. It was faster to put in place and it buys us some time until we can come up with something better. Hope that helps. On Jun 2, 7:44 pm, Tim Hoffman zutes...@gmail.com wrote: Hi I have raised an issue for this http://code.google.com/p/googleappengine/issues/detail?id=3297 Rgds T -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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) ika...@google.com 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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp://qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- You received this message because you are subscribed to the Google Groups Google App Engine group.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com wrote: To reproduce the problem, go to http://qa.connectscholar.com/stylesheets/caSkin.css and also to http://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$ curl http://charityaxis-qa.appspot.com/stylesheets/caSkin.css 1 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curl http://qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- 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.comgoogle-appengine%2Bunsubscrib e...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog:http://googleappengine.blogspot.com Twitter:http://twitter.com/app_engine Reddit:http://www.reddit.com/r/appengine -- 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. -- 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.
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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 rafaeljs...@gmail.comwrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com wrote: To reproduce the problem, go to http://qa.connectscholar.com/stylesheets/caSkin.css and also to http://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$ curl http://charityaxis-qa.appspot.com/stylesheets/caSkin.css 1 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curl http://qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.comgoogle-appengine%2Bunsubscrib e...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog:http://googleappengine.blogspot.com Twitter:http://twitter.com/app_engine Reddit:http://www.reddit.com/r/appengine -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- 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.comgoogle-appengine%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- Ikai Lan Developer Programs Engineer, Google App Engine Blog: http://googleappengine.blogspot.com Twitter: http://twitter.com/app_engine Reddit: http://www.reddit.com/r/appengine
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp://qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- 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
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp://qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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 checking the css files via wget. Thanks for any help regards Tim -- 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
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
In the meantime, I'll investigate whether these headers are being implicitly or incorrectly set. On Wed, Jun 2, 2010 at 12:37 PM, J j.si...@earlystageit.com wrote: Thanks, Ikai, for your help. It is much appreciated. We'll use a cache buster for now. On Jun 2, 3:27 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp:// qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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
Re: [google-appengine] Re: Static files in newly deployed version not available in the apps domain. (Major problem)
I can't reproduce this. Here's my YAML file: application: ikailan-com version: 1 runtime: python api_version: 1 default_expiration: 1d handlers: - url: / script: main.py - url: /assets static_dir: assets Can you guys post your app.yaml? On Wed, Jun 2, 2010 at 1:04 PM, Ikai L (Google) ika...@google.com wrote: In the meantime, I'll investigate whether these headers are being implicitly or incorrectly set. On Wed, Jun 2, 2010 at 12:37 PM, J j.si...@earlystageit.com wrote: Thanks, Ikai, for your help. It is much appreciated. We'll use a cache buster for now. On Jun 2, 3:27 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com wrote: That's interesting, Rafael. I wonder why it serves correctly for you. They are still different from my PoV. The bad side headers: Etag74EQOA DateTue, 01 Jun 2010 18:12:57 GMT Expires Sat, 05 Jun 2010 02:12:57 GMT Content-Typetext/css Content-Encodinggzip Server Google Frontend Content-Length 2820 Cache-Control public, max-age=288000 Age 90134 X-XSS-Protection0 The good side headers: Etag7xGL5w DateWed, 02 Jun 2010 19:13:00 GMT Expires Wed, 02 Jun 2010 19:12:04 GMT Content-Typetext/css Content-Encodinggzip 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) ika...@google.com 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 rafaeljs...@gmail.com wrote: On Wed, Jun 2, 2010 at 3:37 PM, J j.si...@earlystageit.com 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 TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 6146 0 --:--:-- 0:00:01 --:--:-- 31918 Hidan:~ sdm$ curlhttp:// qa.connectscholar.com/stylesheets/caSkin.css 2 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total Spent Left Speed 100 109410 109410 0 2777 0 --:--:-- 0:00:03 --:--:-- 3854 Hidan:~ sdm$ md5 1 MD5 (1) = 8f5ef511be1a03fd73337c334933 Hidan:~ sdm$ md5 2 MD5 (2) = 8f5ef511be1a03fd73337c334933 On Jun 2, 1:18 pm, Ikai L (Google) ika...@google.com 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 j.si...@earlystageit.com 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 zutes...@gmail.com 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
