Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: dev@tomcat.apache.org
Subject: DO NOT REPLY [Bug 52121] New: corrupt gzip output when
 compression=on in server.xml
Date: Tue, 01 Nov 2011 22:15:16 +0000
Message-ID: <bug-52121-78@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=3D52121

             Bug #: 52121
           Summary: corrupt gzip output when compression=3Don in server.xml
           Product: Tomcat 7
           Version: 7.0.22
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Connectors
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: dmarcks@amazon.com
    Classification: Unclassified


Created attachment 27886
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=3D27886
Gzip Corruption Repro WAR

This appears to be same issue as posted by Christopher Taylor
Jun 30, 2011 at 8:05 am to Tomcat Users. The subject line has been preserved
above.

As mentioned in the post, this seems to have arisen with this issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=3D48738

The change introduced this class: FlushableGZIPOutputStream. When we started
using this, we noticed that certain string flush sequences would result in
corrupt gzip output.=20

The attached WAR provides a repro. The sequence of writes to the output str=
eam
that would=E2=80=99ve been done by our server is mimicked in this case usin=
g a file
system. There are 40 files each representing a flush. URL:

"http://localhost:8080/TomcatBugReportWAR"

I=E2=80=99ve allowed the =E2=80=98start=E2=80=99 and =E2=80=98end=E2=80=99 =
request parameters to control to the
starting and ending points. I=E2=80=99ve also allowed an =E2=80=98append=E2=
=80=99 request parameter
dump anything to the outputstream.

The defaults are 0, 40, and =E2=80=9C=E2=80=9D for start end and append res=
pectively.

The following query string appears particularly interesting as it seems to =
be
the smallest sequence that causes the corruption and the subsequent string =
that
is appended after the output is the only thing that appears corrupted:

"http://localhost:8080/TomcatBugReportWAR?start=3D19&end=3D30&append=3Dsome=
thing=E2=80=9D

It=E2=80=99s also possible to reproduce this using only the FlushableGZIPOu=
tputStream
without using Tomcat at all. See attached JAR.

--=20
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=3De=
mail
------- You are receiving this mail because: -------
You are the assignee for the bug.=

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org