maptiler / tileserver-gl

Vector and raster maps with GL styles. Server side rendering by MapLibre GL Native. Map tile server for MapLibre GL JS, Android, iOS, Leaflet, OpenLayers, GIS via WMTS, etc.
https://tileserver.readthedocs.io/en/latest/
Other
2.19k stars 631 forks source link

tileserver ignores Accept-Encoding which breaks clients that does not support gzip-encoded raster tile images #314

Open danpe opened 6 years ago

danpe commented 6 years ago

The issue description can be found here: https://github.com/CartoDB/mobile-ios-samples/issues/20#issuecomment-416119974

The difference seems to be that globekeeper.com has additional HTTP-level gzip encoding in top of jpg. For example tilehosting.com does not use this, as it is not best idea - it makes extra load to both server and client, and does not reduce jpg encoded images much; it can even increase their size in some cases. So for already compressed images like jpg and also png gzip encoding should not be used. The server behaviour is also not compatible with HTTP, the response should take into account request header Accept-Encoding, which SDK does not send, so it should not do compression. Even if I tried to force no compression with Accept-Encoding: identity request header (you can set custom HTTP headers within SDK) then the server keeps sending gzip-encoded data, so this looks like broken server config.

As a quick fix I believe we should move the following lines in serve_data.js

        headers['Content-Encoding'] = 'gzip';
        if (!isGzipped) {
          data = zlib.gzipSync(data);
          isGzipped = true;
        }

inside else if (format == 'geojson')

Although the best way of solving this will be checking the Accept-Encoding header sent from the client.

petrsloup commented 6 years ago

The PBF tiles inside MBTiles are almost always gzipped and most clients (all web browsers, mobile applications, ...) send Accept-Encoding: gzip as the default. This is the most efficient way of serving the tiles -- nothing is decompressed, nothing is recompressed and the content is transferred efficiently.

However, this is indeed not entirely correct behaviour. The server should check the Accept-Encoding header and decompress the content if needed.

I think the quickfix would not work -- it would stop reporting Content-Encoding: gzip, but the tiles inside mbtiles are usually already compressed.

Proper fix should do two things:

PR welcome!