This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 1154 [details] http response to reproduce the error I just discovered that when the Server sets the the content-encoding header field to "bzip2" instead of "x-bzip2", the validator fails to recognize the Format. An example to reproduce the Problem: http://www.solderware.org/pages/index.de.html The server software is Lighttpd Version 1.4.31, its config is not modified with respect to compression headers, so I assume that either lighttpd serves an icorrect header or the validator has a bug. Attached is the example response (including the header). You can reproduce the problem with netcat: "cat resp-incorrect | nc -l -p 8080" and then point the validator to http://your.ip:8080/
For some reason, when the validator says it supports the x-bzip2 encoding (cannot verify on validator.w3.org but it does on my local box), the server decides to send back bzip2 which doesn't seem correct; bzip2 is not a registered content-coding value: http://tools.ietf.org/html/rfc2616#section-3.5 http://www.iana.org/assignments/http-parameters/http-parameters.xml I suspect it'd work if the server sent x-bzip2, but I cannot verify that. On my local box for some reason bzip2 works just fine with the validator, I guess this might be because of differences in libwww-perl versions which is the library handling the response decoding. Anyway, I don't think this is a bug in the validator nor libwww-perl but the server or its config.
(In reply to comment #1) > I suspect it'd work if the server sent x-bzip2, but I cannot verify that. Does anyone have any tips on how to properly (re-)configure lighttpd?
(In reply to comment #2) > (In reply to comment #1) > > > I suspect it'd work if the server sent x-bzip2, but I cannot verify that. > > Does anyone have any tips on how to properly (re-)configure lighttpd? FYI: I've filed http://redmine.lighttpd.net/issues/2443