httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: unsupported compression issue seen in 2.3.5-alpha
Date Sun, 14 Feb 2010 18:00:46 GMT
On Sun, Feb 14, 2010 at 9:46 AM, Rainer Jung <> wrote:
> On 14.02.2010 17:52, Stefan Fritsch wrote:
>> On Saturday 13 February 2010, Paul Querna wrote:
>>> However, the newest reports have been about multiple browsers,
>>> Firefox, Chrome, Safari, and IE8, all reporting the issue at the
>>>  same time.  This makes be believe that the problem is something on
>>>  the server side.
>> I assume your mail here means that the users cannot reproduce the
>> problem at will and provide a tcpdump? Then maybe it would be a good
>> idea to switch back to 2.2.x for some time and see if the number of
>> problem reports changes? Just to verify that it is a problem in httpd
>> trunk and not something else, like e.g. people migrating from squid
>> 2.x to 3.x.
>>> r821471 is the only change in the last year -- and it changes how
>>> buckets are used -- and I view it as suspect in relation to the
>>> volume of reports we have received from users, but we don't have
>>> any firm evidence.
>> There are more changes related to bucket brigade reusing, e.g. r821477
>> and r814807. I guess many other changes in the core are suspect, too.
>> Was the 2.3.5 release the first time that a version containing those
>> bucket brigade changes was installed on
> AFAIK the discussion on the tomcat users list indicated, that the problem
> was for some time reproducible with the eu mirror, but not with the us
> mirror. The reproduction did not work always but roughly about every third
> or fourth attempt. Unfortunately I didn't experience the problem myself,
> otherwise I would've taken a network dump.
> The US mirror seems to run 2.3.3, the EU mirror 2.3.5. I gues it's worth
> checking for differences there, but I wouldn't rely completely on it. Maybe
> network conditions have a subtle influence and were different between geo
> locations during the time the problem was observed by most people.

curl -H 'Accept-Encoding: gzip;' -iL  2>/dev/null |
head -12

What i've been told is, most of the time, this 'works' and you get
compressed data.  But sometimes, the same request returns uncompressed
data, but with the same headers -- implying that mod_deflate was
removed after adding the headers somehow -- this of course will cause
browsers to try to decompress it, but since its already decomrpessed,
it doesn't work.

As far as I know, it has only been reported on 2.3.5 -- not in the
earlier 2.3.3 (which the EU machine also ran before 2.3.5).  If you
search twitter for '' you also see several more reports.

View raw message