mohitsgw / earth-api-samples

Automatically exported from code.google.com/p/earth-api-samples
0 stars 0 forks source link

Support gzip/deflate HTTP compression #121

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
Support HTTP gzip compression via Accept-Encoding header.  This could
significantly reduce KML size and is a 95%+ support in other browsers.

Original issue reported on code.google.com by jsjen...@gmail.com on 14 Dec 2008 at 4:42

GoogleCodeExporter commented 8 years ago
Specifically, with regards to which methods? fetchKml? KmlNetworkLink? You can 
always
use KMZ, which can be compressed. And most common graphics formats are already
compressed.

Original comment by api.roman.public@gmail.com on 16 Dec 2008 at 1:26

GoogleCodeExporter commented 8 years ago
In our case we can just turn on middleware in django to do gzip compression 
with one line of code. Creating 
kmz on the other hand... well that just gets a lot more difficult.

Original comment by underbluewaters on 4 Aug 2009 at 7:15

GoogleCodeExporter commented 8 years ago
Just Google Earth proper needs to support gzip/deflate as an accepting encoding 
for
HTTP responses.  KMZ with its zip format doesn't allow for streaming and is not
appendable like gzip.

Original comment by jsjen...@gmail.com on 4 Aug 2009 at 7:38

GoogleCodeExporter commented 8 years ago
Hi,

I have a question regarding gzip.
Suppose the server adds the “Content-Encoding: gzip” header.
But, the actual content is not gzipped (assuming the compression failed and it 
is sending the data without compression). What will be the impact of this?
How will http clients (especially browsers) handle this?

Thanks,
Narendra

Original comment by ssnku...@gmail.com on 5 Sep 2012 at 11:57