https://bugzilla.wikimedia.org/show_bug.cgi?id=4947
--- Comment #17 from [email protected] 2008-12-17 03:13:19 UTC --- (In reply to comment #15) > SVGZ is pretty ugly to handle because it doesn't have its own Content-Type... > the server is supposed to serve them out with Content-Type: image/svg+xml > *and* > Content-Encoding: gzip... which has the added confusion that the user-agent > would transparently decompress it... and if you save it to disk you'll get the > decompressed version. Transparently decompressing documents with Content-Encoding is a bug. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11 : | The content-coding is a characteristic of the entity identified by | the Request-URI. Typically, the entity-body is stored with this | encoding and is only decoded before rendering or analogous usage. However, support for HTTP/1.1-compliant transparent encoding via TE and Transfer-Encoding headers is still minimal, so Content-Encoding continues to be abused for that with no consistent user-agent behavior (depending on media type). Mozilla behavior for SVGZ depends on user choice between "Web Page, complete" (saves a mangled version of decompressed SVG) and "Web Page, SVG only" (saves original SVGZ, but suggests a filename with .svg appended). > IMHO the cleanest way to go would be to transparently decompress .svgz files > on > upload, normalize everything to .svg, and have the web server transparently > gzip .svg files when serving out, if we like, to save bandwidth. That is the same as sending SVGZ with correct headers from the user-agent's point of view (until TE/Transfer-Encoding are supported), just more expensive on the server side. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
