Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] gzip filter
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 <penhorwood@xxxxxxxxx> 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 <penhorwood@xxxxxxxxx> 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 <laeubi@xxxxxxxxxxxxxx> 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
jetty-users@xxxxxxxxxxx
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
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Back to the top