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
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
Download daemon.req
application/octet-stream 2.8m

Message body not shown because it is not plain text.

From: cstef [...] parallel.ru
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; ------------------------------------------------
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().
From: cstef [...] parallel.ru
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.
Rejecting -- the main issue is already covered by all the other crlf bugs.