Sporatic web attachment corruption

I’m running RT 3.0.4 on a Red Hat 9 machine, with stock Apache 2.0.40
and mod_perl 1.99_07, and I’m seeing some strange web attachment
corruption bugs. It’s happening in the base64 encoding of binary
attachments. (MS Word, PDF, etc) The file size is increased by a few
hundred bytes. I have pasted a section near the end of the same file (a
very simple MS Word document), the first attached correctly, and the
second, incorrectly.

Correct:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9z
b2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA

Incorrect:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAw7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMO+w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/D
v8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/w7/Dv8O/
w7/Dv8O/w7/Dv8O/w7/Dv8O/AQDDvsO/AwoAAMO/w7/Dv8O/BgkCAAAAAADDgAAAAAAAAEYYAAAA
TWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44
AMO0OcKycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

I don’t know if this helps. I can provide the entire attachments
database rows for each instance, as well as the original file, if anyone
wants to take a look. I’m rather stumped, and I don’t know the RT
codebase well enough to debug this through.

My first guess is some sort of (unicode?) encoding issue, but it’s so
intermittent that I’m just not sure.

Any help appreciated,

-Tim
tgerla@outsourcefinancial.com
Outsource Financial Services, LLC.

Hi Tim,

Did you manage to sort this one out? I’m having a very similar issue
with attachments with my RT 3.0.5 / Redhat 9 / Apache 1.3.28 (w/static
mod_perl)

Thanks,
mike

Tim Gerla wrote:

I’m running RT 3.0.4 on a Red Hat 9 machine, with stock Apache 2.0.40
and mod_perl 1.99_07, and I’m seeing some strange web attachment
corruption bugs. It’s happening in the base64 encoding of binary
attachments. (MS Word, PDF, etc) The file size is increased by a few
hundred bytes. I have pasted a section near the end of the same file (a
very simple MS Word document), the first attached correctly, and the
second, incorrectly.

/snip/

I received a report today that this is due to RedHat’s perl build having
its’ locale set funny at build time. if you export LANG=C before
starting RT, it should clear up.On Mon, Sep 22, 2003 at 05:52:56PM -0700, mYK wrote:

Hi Tim,

Did you manage to sort this one out? I’m having a very similar issue
with attachments with my RT 3.0.5 / Redhat 9 / Apache 1.3.28 (w/static
mod_perl)

Thanks,
mike

Tim Gerla wrote:

I’m running RT 3.0.4 on a Red Hat 9 machine, with stock Apache 2.0.40
and mod_perl 1.99_07, and I’m seeing some strange web attachment
corruption bugs. It’s happening in the base64 encoding of binary
attachments. (MS Word, PDF, etc) The file size is increased by a few
hundred bytes. I have pasted a section near the end of the same file (a
very simple MS Word document), the first attached correctly, and the
second, incorrectly.

/snip/


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

We have had the same thing but it seems that in two cases the corruption
occurred from two different corporate networks that probably have proxy
servers in between them and the internet RT server.

When I try to replicate from a direct internet connection the attachments
are ok.

This may be because of sporadic corruptions or related to proxy servers…

RT 3.0.5
RH9
Apache 1.3.28 Static Compiled
mod_perl-1.28

RealFrom: rt-users-admin@lists.fsck.com [mailto:rt-users-admin@lists.fsck.com]
On Behalf Of Jesse Vincent
Sent: Monday, September 22, 2003 8:58 PM
To: mYK
Cc: Tim Gerla; rt-users@lists.fsck.com
Subject: Re: [rt-users] Sporatic web attachment corruption

I received a report today that this is due to RedHat’s perl build having
its’ locale set funny at build time. if you export LANG=C before
starting RT, it should clear up.

Jesse,

A similar solution worked wonderfully:On my RH9 box, i changed /etc/sysconfig/i18n to have LANG=en_US instead of LANG=en_US.UTF-8. This changes the global language for everything, (after a reboot, probably) which is the brute force solution i was looking for, since a lot of the perl modules won’t compile with LANG=en_US.UTF-8. Thanks for your speedy help! Mike Jesse Vincent wrote:

I received a report today that this is due to RedHat’s perl build having
its’ locale set funny at build time. if you export LANG=C before
starting RT, it should clear up.

I received a report today that this is due to RedHat’s perl build
having its’ locale set funny at build time. if you export LANG=C
before starting RT, it should clear up.

I am running it on FreeBSD, so it is not the issue. Also, it is on my
local network, without proxy servers in between. Also, I noticed that
when i restart Apache, it works properly for a while. But I cannot
confirm, I am not 100% that there is connection between.

Regards,

Eng. Dusan Djordjevic (RHCE) PlanetSky Ltd.
Tel: +357 22454896 * Fax: +357-22518022
http://www.planetsky.com dusan@planetsky.com

Yes, I did sort it out. By doing some debugging I learned that the first
attachment per mod_perl apache process worked fine, but subsequent
attachments from the same process failed. I solved the problem by
applying the (possibly incorrect, but working) attached patch.

I’m running Red Hat 9, RT 3.0.4.

Apache server string: Apache/2.0.40 (Red Hat Linux) mod_perl/1.99_07-dev
Perl/v5.8.0 PHP/4.2.2 mod_python/3.0.1 Python/2.2.2 mod_ssl/2.0.40
OpenSSL/0.9.7a DAV/2

-Tim

mYK wrote:

rt.patch (629 Bytes)

I did an export LANG=C and then an httpd restart and the problem seems to be
corrected, but since it is a sporadic problem, it is difficult to confirm.

RealFrom: rt-users-admin@lists.fsck.com [mailto:rt-users-admin@lists.fsck.com]
On Behalf Of Real Carbonneau
Sent: Monday, September 22, 2003 9:35 PM
To: rt-users@lists.fsck.com
Subject: RE: [rt-users] Sporatic web attachment corruption

We have had the same thing but it seems that in two cases the corruption
occurred from two different corporate networks that probably have proxy
servers in between them and the internet RT server.

When I try to replicate from a direct internet connection the attachments
are ok.

This may be because of sporadic corruptions or related to proxy servers…

RT 3.0.5
RH9
Apache 1.3.28 Static Compiled
mod_perl-1.28

Real

From: rt-users-admin@lists.fsck.com [mailto:rt-users-admin@lists.fsck.com]
On Behalf Of Jesse Vincent
Sent: Monday, September 22, 2003 8:58 PM
To: mYK
Cc: Tim Gerla; rt-users@lists.fsck.com
Subject: Re: [rt-users] Sporatic web attachment corruption

I received a report today that this is due to RedHat’s perl build having
its’ locale set funny at build time. if you export LANG=C before
starting RT, it should clear up.