Skip Menu |
 

This queue is for tickets about the MIME-tools CPAN distribution.

Report information
The Basics
Id: 51725
Status: rejected
Priority: 0/
Queue: MIME-tools

People
Owner: Nobody in particular
Requestors: cstef [...] parallel.ru
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 5.427
Fixed in: (no value)



Subject: MIME::Parser::parse_open incorrectly works with strawberryperl on Windows
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Charset: utf8
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1258633139-6514-697"
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
Content-Length: 1319
Download (untitled) / with headers
text/plain 1.2k
I use strawberryperl 5.10.1 on Windows XP and installed mime-tools 5.427 from CPAN. I take the daemon.req MIME file (see attachment). It was produced by Mozilla Firefox (but what is sent over HTTP is also MIME, isn't it?) I has file 'aaa' inside with Content-Type: application/octet-stream. But it is really a test file with Windows CRLF line endings. Then I try to parse it with the following script: ----------------------------------------------- my $file = "C:\\Temp\\mime\\daemon.req"; use MIME::Parser; my $parser = MIME::Parser->new; $parser->output_under("C:\\Temp\\mime"); $parser->parse_open($file); ----------------------------------------------- The resulting file after parsing has UNIX line endings in it. If I change the script: ----------------------------------------------- my $file = "C:\\Temp\\mime\\daemon.req"; use MIME::Parser; my $parser = MIME::Parser->new; $parser->output_under("C:\\Temp\\mime"); open(FH, "<$file"); binmode FH; $parser->parse(\*FH); ----------------------------------------------- everything works fine. I found this bug when I tried to parse file containing .mp3 attachment and got broken file, so it is not as harmless as it looks with text files. The following simple diff works for me in this case, but I am not sure it is always correct (and did not test on Linux).
Subject: daemon.req
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_1258633139-6514-696"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Charset: utf8
Content-Length: 0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: iso-8859-1
Content-Length: 0
Content-Type: application/octet-stream; name="daemon.req"
Content-Disposition: inline; filename="daemon.req"
Content-Transfer-Encoding: base64
Content-Length: 2971748
Download daemon.req
application/octet-stream 2.8m

Message body not shown because it is not plain text.

MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Message-ID: <rt-3.6.HEAD-6514-1258697051-358.51725-0-0 [...] rt.cpan.org>
Content-Type: text/plain
Content-Transfer-Encoding: binary
From: cstef [...] parallel.ru
X-RT-Original-Encoding: utf-8
Content-Length: 659
Download (untitled) / with headers
text/plain 659b
Show quoted text
> The following simple diff works for me in this case, but I am not sure > it is always correct (and did not test on Linux).
I forgot to insert the diff. It follows: ------------------------------------------------ C:\strawberry\perl\site\lib\MIME>diff -u Parser.pm.ORIG Parser.pm --- Parser.pm.ORIG 2008-06-30 23:25:19.000000000 +0400 +++ Parser.pm 2009-11-19 15:15:58.379125000 +0300 @@ -1206,6 +1206,7 @@ my $ent; my $io = IO::File->new($expr) or die "$ME: couldn't open $expr: $!"; + binmode $io; $ent = $self->parse($io); $io->close or die "$ME: can't close: $!"; $ent; ------------------------------------------------
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-18309-1262275256-1456.51725-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 229
Download (untitled) / with headers
text/plain 229b
The parse_open() helper can't really know whether the file needs to be opened with binmode() or not, so your patch isn't really appropriate. You should open the input handle yourself, set binmode if necessary, and call parse().
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-18309-1262275256-1456.51725-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-18309-1262275256-1456.51725-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-10123-1263184897-1605.51725-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: cstef [...] parallel.ru
X-RT-Original-Encoding: utf-8
Content-Length: 635
Download (untitled) / with headers
text/plain 635b
On Thu Dec 31 11:00:56 2009, DONEILL wrote: Show quoted text
> The parse_open() helper can't really know whether the file needs to be > opened with binmode() or not, so your patch isn't really appropriate.
RFC says that line endings in MIME should be CRLF. So really I think if the file is byte-to-byte MIME it has CRLF inside and should be opened binmode. If the file does not have CRLF inside, it is corrupted and it does not care how to open it. Show quoted text
> You should open the input handle yourself, set binmode if necessary, and > call parse().
That's what I am doing now, but I think it is not the best way. Or at least it should be mentioned in the docs.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-26546-1271958987-973.51725-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 74
Rejecting -- the main issue is already covered by all the other crlf bugs.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.