Bug 10409 – SVG fails due to gzip'd javascript

• Status: REOPENED
• Component: SVG

[Eric Seidel (no email)]

SVG fails due to gzip'd javascript

http://www.carto.net/papers/svg/zuerich_migration/index.svgz

I'm not sure if we're supposed to support this or not.  Hyatt or Maciej might know.

curl -I "http://www.carto.net/papers/svg/zuerich_migration/scripts/main.es.gz"
HTTP/1.1 200 OK
Date: Tue, 15 Aug 2006 08:06:29 GMT
Server: Apache/2.0.54 (Linux/SUSE)
Last-Modified: Mon, 09 Aug 2004 15:34:37 GMT
ETag: "1cd80db-14d8-5abfbd40"
Accept-Ranges: bytes
Content-Length: 5336
Content-Type: application/x-gzip
Content-Encoding: gzip
Content-Language: es

[Eric Seidel (no email)]

Here is another SVG which fails for the same reason:
http://www.carto.net/papers/svg/tuerlersee/

[David Kilzer (:ddkilzer)]

(In reply to comment #0)
> curl -I "http://www.carto.net/papers/svg/zuerich_migration/scripts/main.es.gz"
> HTTP/1.1 200 OK
> Date: Tue, 15 Aug 2006 08:06:29 GMT
> Server: Apache/2.0.54 (Linux/SUSE)
> Last-Modified: Mon, 09 Aug 2004 15:34:37 GMT
> ETag: "1cd80db-14d8-5abfbd40"
> Accept-Ranges: bytes
> Content-Length: 5336
> Content-Type: application/x-gzip
> Content-Encoding: gzip
> Content-Language: es

Shouldn't the Content-Type be "text/javascript" with the Content-Encoding marked as "gzip" for this to work?

Does it work in other browsers?

[Alexey Proskuryakov]

This test doesn't work in Firefox either; the content type is definitely supposed to be text/javascript here.

[Andreas Neumann]

I wouldn't use this example as a testcase. It relies on getURL() for loading additional data and does not fork to the XMLHttpRequest alternative. It may also contains additional, non-standard code.

From the examples at http://www.carto.net/papers/svg/samples/ I would only really test the ones marked to work with Op9+ - these are supposed to be standard conform.

Some older examples linked at this pages, still need some renovation (I am working on that).

However, gzipped Javascript is important, since often JS can get very large, esp. in mapping examples, where we sometimes store GIS attributes in Javascript.

Thanks,
Andreas

[Alexey Proskuryakov]

(In reply to comment #4)
> However, gzipped Javascript is important, since often JS can get very large,

Yes, compressed JavaScript should work with Safari, as long as compression is negotiated and used transparently (i.e., the encoding is one of those sent in Accept-Encoding header, and Content-Type of the answer matches the uncompressed content). 

[Brent Fulgham]

This bug appears to be resolved in current WebKit builds.  Please reopen if this problem is still occurring, citing new test cases as the current test cases all pass.

[Brent Fulgham]

My mistake!  The SVG works correctly when gzipped, but the corresponding gzipped javascript fails silently.

[Nikolas Zimmermann]

Changed component to SVG, so it shows up in my all-svg-bugs search.