W3C home > Mailing lists > Public > www-validator@w3.org > August 2016

Re: Corrupt GZIP trailer

From: Michael[tm] Smith <mike@w3.org>
Date: Wed, 3 Aug 2016 06:07:51 +0900
To: "Guus (IFS)" <guus@inspiration-for-success.com>
Cc: www-validator@w3.org
Message-ID: <20160802210751.GZ4628@sideshowbarker.net>
"Guus (IFS)" <guus@inspiration-for-success.com>, 2016-07-30 14:49 +0800:
> Archived-At: <http://www.w3.org/mid/FC1FE218E172437D978F3A5CA3E8ED5C@megaheights.net>
> 
> Recently the validator reports for many or all of my sites. 
> 
> IO Error: Corrupt GZIP trailer
> http://doctorsconnect.ph/

The gzipped file that web server is sending for that resource is definitely
malformed, and that’s why the validator is reporting an error.

You can confirm this on you own by doing this:

  curl -s -H "Accept-Encoding: gzip" http://doctorsconnect.ph/  | gunzip --test

You’ll get this message:

  gzip: stdin: unexpected end of file

Browsers and other tools are more forgiving about that “unexpected end of
file” problem with the response, but the (Java) gzip client library the
validator uses is less forgiving.

Unfortunately I have no ability to make the validator more forgiving for
this case, because the gzip library is 3rd-party code that I just have the
validator source calling into. So I can’t change the behavior of that 3rd-
party code.

> As far as I know nothing has changed in the code/framework I am using
> that could cause this error and I can’t find anything related to it while
> searching in Google.

I think you need to find a way to figure out why the web server is sending
malformed gzip output. If you can’t, then the only way to be able to check
documents from that web server with the validator is to turn off gzip
compression on the server.

  —Mike

-- 
Michael[tm] Smith https://people.w3.org/mike

Received on Tuesday, 2 August 2016 21:08:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 18 August 2016 02:09:59 UTC