Re: [OSM-talk] Old data being cached too long
On Saturday 18 October 2008 05:32:24 you wrote: > I've just grabbed a mapnik tile at random, and these are the headers > sent out with it: > > Date: Sat, 18 Oct 2008 07:20:05 GMT > Server: Apache/2.2.4 (Ubuntu) > Etag: "cb5563ba81dda2fd9bf27cba5a41164f" > Content-Length: 7149 > Cache-Control: max-age=374906 > Expires: Wed, 22 Oct 2008 15:28:32 GMT > Content-Type: image/png > > Therefore, an ISP's transparent proxy should fetch a new version (or > the same one again) after 374906 seconds, or 4.33 days. > > Some ISP's ignore the cache times in their transparent proxies and > therefore should be shouted at. Are any of the tiles you're viewing > older than 4 days? [EMAIL PROTECTED] tiles are every day, as I recall, and > therefore three render cycles could be within the timescale? > Yes, quite older, looks like some yelling is in order. Not that I have much hope for my ISP, I may have to have a script to reload all tiles in the area I'm interested once a week if they don't fix it. > a [EMAIL PROTECTED] headers set: > Date: Sat, 18 Oct 2008 07:27:36 GMT > Server: Apache > Cache-Control: max-age=10800 > Last-Modified: Fri, 17 Oct 2008 10:47:20 GMT > Content-Length: 16457 > Content-Type: image/png > > Which should expire after 3 hours. Notably, this doesn't have a > Expires: header, which means (theoretically) it could get kept longer > as various levels of proxy/cache grab it from each other... > Maybe this would help? > I guess it should expire, but it doesn't affect me right now, I think. I mostly use mapnik, anyway. > It should be that holding down control and pressing refresh in your > browser should request a new version and not accept cached versions, > but I don't know if this matters to javascript or ISP proxies... > Me neither, in any case, it's not practical to refresh each tile. Thank you very much for the info, now it's time to call them. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Old data being cached too long
I've just grabbed a mapnik tile at random, and these are the headers sent out with it: Date: Sat, 18 Oct 2008 07:20:05 GMT Server: Apache/2.2.4 (Ubuntu) Etag: "cb5563ba81dda2fd9bf27cba5a41164f" Content-Length: 7149 Cache-Control: max-age=374906 Expires: Wed, 22 Oct 2008 15:28:32 GMT Content-Type: image/png Therefore, an ISP's transparent proxy should fetch a new version (or the same one again) after 374906 seconds, or 4.33 days. Some ISP's ignore the cache times in their transparent proxies and therefore should be shouted at. Are any of the tiles you're viewing older than 4 days? [EMAIL PROTECTED] tiles are every day, as I recall, and therefore three render cycles could be within the timescale? a [EMAIL PROTECTED] headers set: Date: Sat, 18 Oct 2008 07:27:36 GMT Server: Apache Cache-Control: max-age=10800 Last-Modified: Fri, 17 Oct 2008 10:47:20 GMT Content-Length: 16457 Content-Type: image/png Which should expire after 3 hours. Notably, this doesn't have a Expires: header, which means (theoretically) it could get kept longer as various levels of proxy/cache grab it from each other... Maybe this would help? It should be that holding down control and pressing refresh in your browser should request a new version and not accept cached versions, but I don't know if this matters to javascript or ISP proxies... Tristan 2008/10/18 Matias D'Ambrosio <[EMAIL PROTECTED]> > > I thought there were some errors with OSM but today visiting a friend we used > OSM and mapnik was looking just fine, no tiles were old, while at home I get > a patchwork of new and old, and I have to hit reload a bunch of times to get > the right one. It's not my cache, btw, I did check for that :-) (Besides, I > use multiple browsers and they all looked exactly the same.) > There is the small chance that OSM is doing something wrong that might cause > this, but in all likelihood it's my ISP doing business as usual. I know they > use a transparent proxy, which is quite opaque as this case shows, but not > being a proxy-knowledgeable person, I don't know exactly what they broke in > theirs. I see some tiles that are at least two render-cycles old (more than a > week and a half), and reloading each tile manually is quite annoying, plus > it's one, if not *the*, largest ISP in Argentina. Could anyone tell me the > right keywords? What bits to flip? Tomorrow is saturday and I'll be doing > some work with plenty of dead time for me to call their toll-free number and > see if I can get someone who can talk beyond the scripted responses (I talked > with one such person a few years ago), who knows, they might fix it if I > provide them with the right info. > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Old data being cached too long
I thought there were some errors with OSM but today visiting a friend we used OSM and mapnik was looking just fine, no tiles were old, while at home I get a patchwork of new and old, and I have to hit reload a bunch of times to get the right one. It's not my cache, btw, I did check for that :-) (Besides, I use multiple browsers and they all looked exactly the same.) There is the small chance that OSM is doing something wrong that might cause this, but in all likelihood it's my ISP doing business as usual. I know they use a transparent proxy, which is quite opaque as this case shows, but not being a proxy-knowledgeable person, I don't know exactly what they broke in theirs. I see some tiles that are at least two render-cycles old (more than a week and a half), and reloading each tile manually is quite annoying, plus it's one, if not *the*, largest ISP in Argentina. Could anyone tell me the right keywords? What bits to flip? Tomorrow is saturday and I'll be doing some work with plenty of dead time for me to call their toll-free number and see if I can get someone who can talk beyond the scripted responses (I talked with one such person a few years ago), who knows, they might fix it if I provide them with the right info. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
