I've been tearing my hair out trying to get GZIP compression to work for a standard Azure Web Site which is using ASP.NET MVC 5.
Does anybody have a definitive guide to setting up the web.config or applying a custom attribute?
I've tried everything I usually use locally such as supplying GZIP/DEFLATE content encoding header but to no avail.
I'm beginning to think it doesn't work in the standard web site but I thought I should ask first..
Cheers
-- Update.
I am not getting any errors, (I as far as I can tell) am checking the Accept-Encoding header, and adding a Content-encoding header in return with the value gzip. However when I try to check the headers in Chrome/Firefox on the live site it does not seem to be working.
e.g. Locally
GET / HTTP/1.1
Host: localhost:34249
Connection: keep-alive
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,fr;q=0.4
Cache-Control:public, max-age=15
Content-Encoding:gzip
Content-Length:22900
Content-Type:text/html; charset=utf-8
Date:Wed, 13 Aug 2014 20:18:47 GMT
Expires:Wed, 13 Aug 2014 20:19:00 GMT
Last-Modified:Wed, 13 Aug 2014 20:18:45 GMT
Vary:*,Accept-Encoding
X-Frame-Options:DENY
X-SourceFiles:=?UTF-8?B?QzpcV29ya1xCbG9nXEJsb2c=?=
On Azure...
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en;q=0.8,en-US;q=0.6,fr;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:ARRAffinity=2f6641fa653941a3835129cf27dd73a8f366413851cb89c13e53d88bf9cadc19
Host:<bla>
Pragma:no-cache
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
Cache-Control:public, max-age=8
Content-Length:44549
Content-Type:text/html; charset=utf-8
Date:Wed, 13 Aug 2014 20:20:03 GMT
Expires:Wed, 13 Aug 2014 20:20:12 GMT
Last-Modified:Wed, 13 Aug 2014 20:19:57 GMT
Vary:*,Accept-Encoding
X-Frame-Options:DENY
As you can see no content encoding parameter. Let me know if you need any more information. Cheers J
Apologies I thought I had already closed the question. It seems I was going through a proxy which was stripping out GZIP in this particular example.
SyntaxC4 - Many thanks for the cheat sheet I'm sure it will become useful later if I require IP blocking.
Cheers,
J
Related
I've set up my simple website with valid Let's Encrypt SSL certificate (from certbot). My nginx config is very short and trivial.
Website shows up correctly in latest Firefox. It shows 404 page, which is OK to me and should work as expected: 404 page.
If I try Google Chrome, i get an error:
The webpage at https://example.org/ might be temporarily down or it
may have moved permanently to a new web address.
ERR_INVALID_SIGNED_EXCHANGE
I assume that the application/signed-exchange header may cause this.
What is this header and should i remove it from response?
Request
GET / HTTP/1.1
Host: example.org
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,ru;q=0.8
DNT: 1
example.org example.org
Response
HTTP/1.1 404 Not Found
Server: nginx
Date: Fri, 29 Mar 2019 12:05:49 GMT
Content-Type: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3
Content-Length: 345
Connection: keep-alive
What to fix?
The Content-Type in the response is incorrect. It should be a single type, as Steffen Ullrich said. For a 404 page, I suspect you want Content-Type: text/html.
This may be something particular to your nginx config. On my server, 404 pages have Content-Type: text/html.
I have a Server 2012 R2 box running IIS. I've tried enabling compression for several sites running on that box, but I can't figure out why it won't work. My request headers all show accept-encoding, but the response headers are always Transfer-Encoding:chunked and Vary:Accept-Encoding. The following steps have been performed to try to get gzip compression working:
Dynamic and Static compression have been enabled on each site and at the machine level
Both compression methods are installed from Server Manager
Httpcompression and urlcompression nodes have been manually added to web.configs
Mime types are defined for compression
frequentHitThreshold has been set to 1, so all content should be compressed after the first attempt to access it
A trace has been done to see why compression isn't occurring. The only information I have is the code DYNAMIC_COMPRESSION_NOT_SUCCESS with a reason of 1.
Here are the headers:
GET http://redactedservername:8082/ HTTP/1.1
Host: redactedservername:8082
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
DNT: 1
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: ASP.NET_SessionId=gnqovt55ggt22lycufudc0ns
`
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Date: Wed, 22 Jun 2016 14:00:57 GMT
Transfer-Encoding: chunked
What other steps can be performed to get compression to work?
Compression was working, but ESET Antivirus was doing its job of monitoring web traffic. This modified the response and I didn't get gzip content encoding as expected. Disabling ESET and testing again showed that compression was functioning.
I have a Tomcat server running on Linux. When viewing a png on Chrome in Windows, this image looks like this
http://imgur.com/x08QkUD in contrast the image on any Unix system: http://imgur.com/OIk84Cb
As you can see it is totally corrupted. Viewing the image in any Unix system it looks just fine (Without all those yellow weird lines).
If I look at this in Firefox (Windows), the browser response with "Cannot display this image because it contains errors"
Here is my request and response headers for this image (this is the same Response, Request as on a Unix system)
Request Method:GET
Status Code:200 OK
Response Headers
view source
Accept-Ranges:bytes
Content-Length:15432
Content-Type:image/png
Date:Tue, 01 Sep 2015 17:21:23 GMT
ETag:W/"15432-1441113486000"
Last-Modified:Tue, 01 Sep 2015 13:18:06 GMT
Server:Apache-Coyote/1.1
Request Headers
view source
Accept:image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Host:148.251.217.3
Pragma:no-cache
Referer:http://148.251.217.3/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135
Is there anything that I can change in Tomcat to change this weird behavior?
I am thinking of mimetype, compression, ...
I have basically have the default configuration of Ubuntu 15.04 just now
What is the best way to get IIS to set the headers for woff files so that they can be served from the client browser cache.
I'm working on an MVC .NET site that is hosted in IIS7.5, served through cloudflare with static caching turned on. The site uses a custom woff web font. When requests are made for pages that use these fonts IIS is serving them with the headers shown below. Subsequent requests all look the same. To me it looks like these are not getting cached by the client browser. I'd expect the server to be responding with 304 (Not Modified) and then the browser should serve the woff from its cache.
Request Headers
GET /blah/Content/fonts/AzoSans-Thin-webfont.woff HTTP/1.1
Host: blah.co.uk
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Accept: */*
DNT: 1
Referer: http://blah.co.uk/bundles/Content/stylesheets/main?v=f9NXr53WMUdV9DfYJMkEU_5QZZi0g8eB1lB5lqxgdXc1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: __cfduid=d96b367152ae58725c15e5946cf1d67f41415385741070; ASP.NET_SessionId=3tcc3e1nd0z005tlknrbph5h; redesign#lang=en
Response Headers
HTTP/1.1 200 OK
Date: Fri, 07 Nov 2014 19:27:57 GMT
Content-Type: application/font-woff
Content-Length: 27728
Connection: keep-alive
Last-Modified: Thu, 06 Mar 2014 10:40:46 GMT
ETag: "0cbfc872839cf1:0"
X-Powered-By: ASP.NET
CF-Cache-Status: HIT
Vary: Accept-Encoding
Expires: Fri, 07 Nov 2014 23:27:57 GMT
Cache-Control: public, max-age=14400
Accept-Ranges: bytes
Server: cloudflare-nginx
CF-RAY: 185bee60092d0a90-LHR
The problem here seems to be that cloudflare is changing the headers. If I bypass cloudflare I get
Cache-Control:max-age=0
and the server responds with a 304 and the browser uses content from its cache.
Gzipping static files does not work as required (as I think). I used gzippo and express.compress(). Both gzipp the files one time. There is no Content-Encoding:gzip if I refresh the page again.
Her is how I setup my express app:
var gzippo = require('gzippo');
var express = require('express');
var app = express();
app.use(express.compress());
app.use(app.router);
app.use(gzippo.staticGzip(__dirname + '/www'));
This is what Chrome network Response Headers show after page update:
EDITED for full request headers
GET / HTTP/1.1
Host: myhost.com
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/ *;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: __utma=161759779.498387976.1381482631.1394444924.1394395346.80; __utmb=161759779.3.10.1394395346; __utmc=161759779; __utmz=161759779.1394444924.79.7.utmcsr=gtmetrix.com|utmccn=(referral)|utmcmd=referral|utmcct=/reports/myhost.com/5iXAs1ej/retest
If-None-Match: "25020-1394452200000"
If-Modified-Since: Mon, 10 Mar 2014 11:50:00 GMT
If I refresh again it shows: Edited with full response headers.
HTTP/1.1 304 Not Modified
x-powered-by: Express
accept-ranges: bytes
etag: "25020-1394452200000"
date: Mon, 10 Mar 2014 10:51:45 GMT
cache-control: public, max-age=0
last-modified: Mon, 10 Mar 2014 11:50:00 GMT
If I edit the page again I get Content-Encoding:gzip but only one time.
I don't know if there is something wrong with my express setup.
NOTE: I serve my page as: res.sendfile(__dirname + '/www/index.html');
If I edit the page again I get Content-Encoding:gzip but only one time. I don't know if there is something wrong with my express setup.
All is well. The first time your server sends the file with gzip compression. The second time the normal etag cacheing mechanism comes into play, and since the file has not been modified, the server tells the browser "you already have the right version of this file" and thus there is no need for the server to send a response body at all, just headers, thus no need for any Content-Encoding header.