I have some html files stored on Amazon s3, some are quite large so the plan was to store them gzipped and return that as the encoding type when receive a request for them, is that how it works rather than server having to encode them.

Can the file still end as .html even if in gzip format. I know the server should check what encodings the user/browser supports and then return the correct format but not sure if I have to code that bit of it is handled by Tomcat.

  • You could end it with .peanutbutterjellytime if you like.... as long as the MIME type is process corrected. GZIP in browsers will deflate the file before processing, meaning its still the original format to the end-user. Jun 29 '15 at 17:29
  • Okay what about if the user/browser doesnt support gzip ? Jun 29 '15 at 17:34
  • How many people do you know who still use browsers that are more than 15 years old? :) webmasters.stackexchange.com/questions/22217/… Browsers have been using GZIP since early 2000 Jun 29 '15 at 17:39
  • @BYBE So its a non-problem so if just quietly replaced all my .html files on s3 with a gzipped version with same name I shoudn't have any problems, and if I use Cloudfront in front of S3 that wont cause any issues ? Jun 29 '15 at 20:08
  • Nowadays its considered a good practice to have gzipped enabled, so yes you should not encounter any major problems. Jun 29 '15 at 20:56

My question is why. Why use .html when you can use friendly URL's instead?

Anyways, technically, you could but the important thing that determines how the browser handles the data is the HTTP content-type header.

In a standard HTML document, the content type header will contain at least this:

Content-type: text/html

Some may go as far as this in order to specify the character encoding of the page:

Content-type: text/html; charset=UTF-8

With regards to serving gzipped html pages, the proper way to do it is to first compress the HTML in a gzip format, then output the compressed data after the usual HTTP headers including the following headers at minimum:

Content-type: text/html
Content-Encoding: gzip

For browser compatibility, you can also include:

Vary: Accept-encoding

That way, you can serve compressed and uncompressed content. Here's code in php to help you understand things better. Feel free to save it as a file with a PHP extension, and yes the compression will still work:

header("Content-type: text/html",true);
header("Vary: Accept-Encoding",true);
if (strpos(strtolower($_SERVER['HTTP_ACCEPT_ENCODING']),"gzip") > 0){
//browser supports gzip
header("Content-Encoding: gzip",true);
header("Content-length: ".strlen($myhtml),true);
echo $myhtml;

First, a file is fetched locally in the server and the contents of it are stored in a myhtml variable. Next, the minimum headers are prepared. Then the system checks to see if browser supports gzip extraction by checking the incoming accept-encoding header. If it does, then the gzip encoding HTTP header is prepared and contents are myhtml are then compressed. Finally, regardless of the support for gzip, the length of the document is based on the number of bytes of the contents of myhtml. Finally its printed on screen.

  • Why ? - originally the urls had no .html extension but I ran into an issue stackoverflow.com/questions/30706218/… and now google has started indxing the .html urls I thought maybe just leave them as is, but if I had no suffix in the url the question would be much the same but anyway I think youve cleared things up for me. Jun 30 '15 at 7:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.