Tegola sends gzipped tiles when it shouldn't

[pnorman]

Web browsers send Accept-Encoding: gzip and Tegola returns compressed data, as it should

$ curl -D headers -s 'http://localhost:8080/maps/bolder/0/0/0.pbf' -H 'Accept-Encoding: gzip' | file -
/dev/stdin: gzip compressed data

It also sets content-encoding correctly

$ cat headers
HTTP/1.1 200 OK
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Content-Length: 60957
Content-Type: application/vnd.mapbox-vector-tile
Tegola-Cache: HIT
Date: Thu, 28 Feb 2019 07:29:03 GMT

Requests which say noting about encoding acceptability are also gzip encoded. This is unusual, but not prohibited. It does make some debugging harder, because it's then behaving differently than other HTTP servers.

$ curl -D headers-s 'http://localhost:8080/maps/bolder/0/0/0.pbf' | file -
/dev/stdin: gzip compressed data

Even though it's sending gzipped encoded data, it's not setting Content-Encoding. This is non-compliant.

$ cat headers
HTTP/1.1 200 OK
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Origin: *
Content-Length: 60957
Content-Type: application/vnd.mapbox-vector-tile
Tegola-Cache: HIT
Date: Thu, 28 Feb 2019 07:28:30 GMT

If accept-encoding is set and doesn't contain gzip, Tegola sends gzipped data

$ curl -D headers -s 'http://localhost:8080/maps/bolder/0/0/0.pbf' -H 'Accept-Encoding: bt, identity' | file -
/dev/stdin: gzip compressed data

Tegola ignores the Accepting-Encoding header and always sends gzip-encoded data. The RFC states that tegola SHOULD send a response without any content-encoding (identity encoded), and Tegola violates this. It does set the gzip header correctly.

If Tegola is explicitly told that gzip is not acceptable, it still sends gzip

$ curl -D headers -s 'http://localhost:8080/maps/bolder/0/0/0.pbf' -H 'Accept-Encoding: bt, identity, gzip;q=0' | file -
/dev/stdin: gzip compressed data

It does not set the Content-Encoding header, which is non-compliant.

The setting of the Content-Encoding header is new to me - it shows that some parsing of Accept-Encoding is going on.

ref #438

[ARolek]

@pnorman that's for the detailed issue. This looks related to #552.

[pnorman]

@pnorman that's for the detailed issue. This looks related to #552.

Yes - fixing all of the issues here should fix #552. It's hard to say which of the spec violations is causing #552, but in general violating the spec can confuse proxies.