Have raised bug:- https://bugs.eclipse.org/bugs/show_bug.cgi?id=457309
On 13 January 2015 at 20:27, "" <[email protected]> wrote: > 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
