TYPO3 Core

Sorry, the additional information was wrong. You have to change the lines like this:

function gzip_accepted() {
    if (strpos(getenv("HTTP_ACCEPT_ENCODING"), 'gzip') === false) {
        return false;
    } else {
        $encoding = 'gzip';
    }

The bug is still present in 4.0.5 and 4.1. It would be cool if you could fix it with the next release since I don't want to do it manualy on each update.

Thx.

From RFC 2616:
gzip An encoding format produced by the file compression program
"gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
Lempel-Ziv coding (LZ77) with a 32 bit CRC.

compress
        The encoding format produced by the common UNIX file compression
        program "compress". This format is an adaptive Lempel-Ziv-Welch
        coding (LZW).

Use of program names for the identification of encoding formats
        is not desirable and is discouraged for future encodings. Their
        use here is representative of historical practice, not good
        design. For compatibility with previous implementations of HTTP,
        applications SHOULD consider "x-gzip" and "x-compress" to be
        equivalent to "gzip" and "compress" respectively.

Addionally we should also consider the "qvalue".

The qvalue simply gives a hint which encoding the browser prefers. But to keep it short: With the current HTTP implementation there is only the option whether to encode with gzip or send the page uncompressed. x-gzip or compress isn't good at all since it is historical and not a "good design" (IE7 even doesn't understand it anymore).

IMHO we should only change the lines as proposed (Note 08.12.06, 12:21) and don't blow the hole thing up with qvalues which doesn't have an advantage in real life.

Björn, you're the one started this issue and referred to the RFC. So, to be consequent I added a check against the qvalue. See the attached patches (_w is without whitespace changes).

IMO the gzip thing is only have of the way. It is processed each request to a website. For the 4.2 or 4.x development we could possibly consider partial caching of this functionality.

Oliver, I appreciate your engagement, but I don't think we should support x-gzip anymore (as proposed in the RFC).

My problem is that the T3 pages are cached by a proxy. If a browser, which supports x-gzip visits the site and the page is beeing cached x-gziped, a second visiter who uses IE7 will get the x-gziped page too. As a result the IE7 visitor gets only some scambled lines of code.....

If we keep the x-gzip support, I have to deactivate the page compression to prevent trouble with the proxy.

Did you have a look at the patch? No always "gzip" is in the response, even if the browser states to support "x-gzip". The HTTP/1.0 specs already referred to gzip for future disposal.
Just try the patch, modify it if there is something missing and afterwards post it here.

I'm fine with that as long as x-gzip isn't used anymore ;-)

Could you please test, if the patch solves the problem? If so, I'm going to put this to the Core list.

Hi Oliver!

I applied the 0004623_w.patch to my test environment and did some changes in my Firefox settings to force the x-gzip encoding. Without the patch the IE was striking. With the applied patch everthing was fine :-)

+1 for the patch.

Regards
Bjoern

http://www.phoenix-medien.de

I'm going to add some JavaDoc comments to the affected class and post the patch to the Core List end of this week.

Okay, I made one small change, added several missing JavaDoc comments and fixed spacing/tabs of the whole file.

Hi Oliver!

The patch you developed works on are sites for several months now without any props. Is it already in the svn?

Regards.

Thanks for the reminder! I'm going to commit this ASAP.

• TYPO3_4-0 (rev. 2370) -- for TYPO3 4.0.7
• TYPO3_4-1 (rev. 2371) -- for TYPO3 4.1.2
• Trunk (rev. 2372) -- for TYPO3 4.2dev