On Thu, 2010-02-18 at 13:57 +0100, Guilhem Bonnefille wrote: > Thanks for this explanation. > > I'm not sure to understand why you don't support last-modified.
I can turn on the If-Modified-Since but this makes the ETag useless. The rules of the HTTP specification mean that if it fails the If-Modified-Since check because it has been re-rendered then you will download the whole file again regardless of whether the content is unchanged and the ETag still matches. > I understand that ETag allows to handle new tile with same content. > But it is more complex as it need to store metadata for the tile. Correct. > With last-modified solution, we simply have to send the timestamp of > the file (a metadata already stored by any filesystem). Of course, we > don't avoid new file with same content, but I expect we can avoid some > downloads in many case. If you don't store any state for the file then you are also throwing away the expiry hints which the server is also providing. It would be nice to keep hold of this data in a simple DB, sqlite would probably fit this quite well. > Is it possible to imagine both system: > - last-modified for simple client > - Etag for evolved client I did experiment with a few combinations but concluded that we need to pick one or the other. Ideally I would like to use the ETag system because it is more cache friendly. At the moment we can handle the HTTP traffic from a single central web server but if the web traffic increases much further then we are going to need to offload some traffic to remote web caches (acting as reverse proxies). > > 2010/2/17 Jon Burgess <jburgess...@googlemail.com>: > > On Wed, 2010-02-17 at 21:43 +0100, Jocelyn Jaubert wrote: > >> Hi Guilhem, > >> > >> Le 16 février 2010, Guilhem Bonnefille a écrit : > >> > 2010/2/7 Greg Troxel <g...@ir.bbn.com>: > >> > > I don't see how to set the new 'tiles fresh enough' paramater. It > >> > > seems OSM mapnik updates from minutely tiles; it's cool to grab > >> > > them when you want, but a lot of server load normally. I suggest a > >> > > week for the default fresh-enough-not-to-ask time, but I don't see > >> > > how to set that in the GUI and I don't see it in the viking file. > >> > > >> > I added a preference for setting this value dynamically. Check Git > >> > repo at SourceForge. > >> > > >> > But I fear that this feature is no more functional: I did many tests > >> > and I feel tiles are always downloaded (from tile.openstreetmap.org). > >> > Jocelyn, as you are the author of this feature, can you give it a try? > >> > >> I have looked at what is sent to the server, and received from it (via > >> the -V switch) and it seems that tile.openstreetmap.org returns a tile > >> even if it was not updated on the server. > >> > >> But if you try on the OSM server, then it works correctly: no tile is > >> sent by the server if viking already has a recent tile. > > > > Do you mean that the osmarender server works as you expect here? > > > > > > I wrote the mod_tile code which serves the tiles from > > tile.openstreetmap.org and can give you some background on the current > > behaviour. We made a decision to make use of the ETag header instead of > > the last-modified field. Tiles often get re-rendered without the > > contents changing. If we used the last-modified time then this would > > result in the tile being downloaded unnecessarily. > > > > Instead, we return an ETag header in the HTTP response for each tile > > which is derived from the md5sum of the tile. If the tile gets > > re-rendered and the content is identical to the previous tile then the > > ETag should match even if the last-modified-time was updated. > > > > > > When the client makes a request it should store the ETag returned. When > > it comes to request the tile again the client includes this ETag in a > > If-None-Match header. If the current tile on the server still has the > > same content then this will trigger a 304/NotModified response. I have > > included an example of in an attachment. > > > > We also return "Expires:" and "Cache-Control:" headers which can assist > > the client in deciding when to try requesting the tile again. > > > > All these headers are defined in the various HTTP RFCs. In theory, > > properly written web browsers and caches should work fine with them but > > I am beginning to wonder whether I should discard the ETag and move back > > to a simple last-modified time system. > > > > Jon > > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > Viking-devel mailing list > > Viking-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/viking-devel > > Viking home page: http://viking.sf.net/ > > > > > ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
