[Geoprisma-dev] Caching on client-side, TileCache example

[Yves Moisan]

Le vendredi 06 novembre 2009 à 10:18 -0500, Alexandre Dube a écrit :
> Devs,
> 
>   I'd like to discuss an important matter : caching on the client-side 
> browser in GeoPrisma, most particularly "TileCache" tiles returned by 
> the Proxy.
> 
> === Is it wrong ? ===
> 
>   The first thing that comes to my mind is that GeoPrisma is an 
> "access-controled" application, so caching tiles on the client side 
> could be wrong.  For example :
>    User "A" has access to some tiles (from sensitive data)
>    He visits his application on a public station and the browser caches 
> the tiles
>    Then he logs off (leaving the cache there)
> 
>    User "B" doesn't have access but he's smart and evil
>    He goes directly in the cache folder and "voilà"
>    Or the same tile request that are cached won't reach GeoPrisma proxy 
> since they are cached and will return "304" response....
> 
>   In brief, client-side caching really seems to be wrong in a secured 
> environment, but it's quite annoying to be waiting for query responses 
> (tiles) you should normally have while browsing your map, like zooming 
> in and out and in and out always makes the same requests but without any 
> caching it becomes much slower...

Well, I'm not an Apache guru, but I was thinking how a logout could
triggers a server-side event to clear the cache of GP items (if at all
possible).  Anyhow, I ended up on this url :
http://www.mediawiki.org/wiki/Manual:Configuration_settings#Client_side_caching

Basically, we could do like MediaWiki and provide an option to set
caching on or off.  I don't see it other than : you have a choice to
*really* speed up you application by turning client-side caching but
there are some risks.  Organizations that want speed and top security
could inform user A to not use public machines.  I don't know what they
can do for user B though.  

It definitely is a PITA to wait for tiles to show up.  The problem I
found is particularly acute when zooming back out.  Heck, you were at
zoom level N, went at N+1 for a minute, and when you zoom back out to N
it takes for ever to see an image.  Kills the TileCache IMO.  So my
position now would be : let's create a client-side caching option and
document its shortcomings.  Most organizations will probably live with
the risks (which can probably be somewhat alleviated) to get a *fast*
mapping application.

> 
> === Caching currently in GeoPrisma ? ===
> 
>    Currently, GeoPrisma doesn't cache tiles at all on browser-side.  I 
> made some tests to verify that fact with the lastest trunk version of 
> TileCache that now has X-SendFile support.  I tested with mod_sendfile 
> and it works perfectly.  

I get an "Expires" header in the response using mod_expires on a TC
layer (old TC version).  Could you document your Apache settings with
sendfile ?  Do you know in which version of TC X-SendFile support was
introduced ?

> The first query directly sent to the tilecache 
> service returns an "Expires" tag that is read by the browser and used 
> for caching :
> 
>    === tilecache query on the service directly ===
> 
> curl -I 
> "http://127.0.0.1:8087/tilecache/tilecache.py?LAYERS=gmap_base&BBOX=860892.7437255,-935783.25,2667113.9905882,870437.99686275&REQUEST=GetMap"
> 
> HTTP/1.1 200 OK
> Date: Fri, 06 Nov 2009 14:40:18 GMT"200" and the same request made after 
> returns "304", see :
> Server: Apache/2.2.11 (Unix) PHP/5.2.9 mod_python/3.3.1 Python/2.6.2
> Expires: Fri, 06 Nov 2009 15:40:18 GMT
> Last-Modified: Fri, 06 Nov 2009 14:27:36 GMT
> Content-Length: 11451
> ETag: "477b4a52f4600"
> Content-Type: image/jpeg
> 
> 
>   Using the same TileCache service but going through the GeoPrisma Proxy 
> reveals some more tags with "no-cache" added.  Therefore, the Proxy 
> prevents caching.

Client-side ?

> 
> curl -I 
> "http://127.0.0.1:8087/geoprisma/demo/proxy.php?osmservice=S_TC_DEV4G&osmtoken=TODO 
> Delete 
> this&osmresource=R_GMAP_BASE&FORMAT=image%2Fjpg&LAYERS=gmap_base&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A42304&BBOX=860892.7437255,-935783.25,2667113.9905882,870437.99686275&WIDTH=256&HEIGHT=256"
> 
> HTTP/1.1 200 OK
> Date: Fri, 06 Nov 2009 14:40:16 GMT
> Server: Apache/2.2.11 (Unix) PHP/5.2.9 mod_python/3.3.1 Python/2.6.2
> X-Powered-By: PHP/5.2.9
> Set-Cookie: PHPSESSID=f420f531163be39d51d519f6b61ea6a0; path=/
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
> pre-check=0
> Pragma: no-cache
> Connection: close
> Content-Type: text/html


Here's what I get :

Date	Fri, 06 Nov 2009 16:07:52 GMT
Serve	rApache/2.0.54 (Win32) PHP/5.2.1
X-Powered-By	PHP/5.2.1
Expires	Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control	no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma	no-cache
Content-Length	475
Keep-Alivetime	out=15, max=100
Connection	Keep-Alive
Content-Type	text/html
> 
> 
> === Do we want caching in GeoPrisma ? ===
> 
>   My first though is 'yes', since it comes with a big performance 
> improve while using the application.  We should list the potential flaws 
> it can creates and find a way to fix them.
> 
>   What are your thoughts on that subject ?

See above.  I'm +1 for a "cacheImages" option.  Slowness in showing
TC'ed images is a pain.

Yves
>