Tested with firefox & chrome. It is gzipped when using a browser. The responses look OK and there are is no missing response header.
*HOWEVER*, there something fishy here..... testing with curl david@server:~$ curl -I --header "Accept-Encoding: gzip" http://home.coldbits.com/ HTTP/1.1 200 OK Date: Tue, 13 Jan 2015 06:36:21 GMT Content-Type: text/html Last-Modified: Tue, 13 Jan 2015 01:35:33 GMT Accept-Ranges: bytes Cache-Control: max-age=3600,public ETag: W/"bcUlaFWYXoUbcUkILV2M+k" Content-Length: 5737 Server: Jetty(9.2.6.v20141205) The responses is not gzipped.... *curl -I does an HTTP HEAD request..*. So, perhaps that the sites that found the response was not gzipped, had looked at the response headers to a HEAD request rather than a GET. I believe this is perhaps deliberate by the jetty authors. As there is no response body for a HEAD request they have saved on the gzipping to work out what the size of the gzipped response would be. I sort of think *this is wrong*; the response headers to a HEAD request should be the same as they would be for a GET request; that the whole purpose of a HEAD request. Now when I do a HEAD request against a site I have running Varnish with Varnish doing the compression, I see that I get gzipped response headers. I do see variability between sites on this. Looking at the RFC http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html 9.4 HEAD The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. The response to a HEAD request MAY be cacheable in the sense that the information contained in the response MAY be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale. We see that it sort of indicates that Varnish does things right by the RFC and Jetty does not.... *Additionally*, it is interesting that jetty returns a different etag value depending on whether the content is gzipped or not.... This means that the etag returned to a HEAD request is different to the etag returned in a GET request..... *This a big big no no.* /David On 13 January 2015 at 14:59, Andrew Penhorwood <[email protected]> wrote: > I have setup a test page. http://home.coldbits.com > > The page is HTML5 about 5.6k, displays the filter as configured on the > site plus some filler text. > > While some testing tools say yes it is compressed it appears few of them > really work. I found http://gzipwtf.com/ to be one that gave good > results on multiple pages. > > One page said the problem might be the that the "Content-Encoding" header > appears to be missing from the response. > > Feel free to hit the page and see what you get. So far I am at a loss on > how to fix it. > > Andrew > > On Mon, Jan 12, 2015 at 10:50 AM, Andrew Penhorwood <[email protected]> > wrote: > >> Not in a reliable why it appears. I will use a better client or write >> something to verify that information. Chrome has been my client and it >> says no compression as far as I can tell. This all started by using the >> audit tab in the chrome developer tools. According to the audit report the >> files are not being compressed. >> >> On Mon, Jan 12, 2015 at 10:45 AM, Christoph Läubrich < >> [email protected]> wrote: >> >>> Have you verified that it reports compressed resources (e.g. other >>> website you know that use GZIP)? As mentiones while Firebug shows >>> compressed size IE shows uncompressed size in the debug panel but neither >>> of those really "show" that it was gzipped directly! >>> >>> Am 12.01.2015 12:32, schrieb Andrew Penhorwood: >>> >>>> I am using chrome and I can see the gzip accept headers in the >>>> request. I can also see that the file size never changes when it comes >>>> across the wire. >>>> >>>> >>>> >>> _______________________________________________ >>> jetty-users mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/jetty-users >>> >> >> >> >> -- >> Andrew Penhorwood >> [email protected] >> www.coldbits.com >> > > > > -- > Andrew Penhorwood > [email protected] > www.coldbits.com > > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users >
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
