Re: [soaplite] Re: Possible bug in handling MIME messsage?
- I am going to contact Eryq, the maintainer of MIME::Tools and see if I
might be able to see what he thinks. He has helped SOAP::Lite in the
past by issuing patches for us. He has good insight into the users of
MIME::Tools, the users of SOAP::Lite being a small minority. Let's get
Duncan Cameron wrote:
> At 2004-10-26, 21:37:14 jpeyser <jpeyser@...> wrote:
> >After much debuging, I think I found the problem.
> >In Mime Tools module Mime/Parser/Reader.pm, at the end of sub
> >read_chunk, the following line removes all trailing \r and \n,
> >regardless of order.
> > ### Write out last held line, removing terminating CRLF if ended
> >on bound:
> > $last =~ s/[\r\n]+\Z// if ($eos =~ /^(DELIM|CLOSE)/);
> >It should read
> > $last =~ s/(?:\r\n)+\Z// if ($eos =~ /^(DELIM|CLOSE)/);
> I think that I reported this problem to the list earlier this week, and
> have also raised it on the CPAN bug tracking system.
> I think we need to be careful as to what the fix should be though. Your
> example allows any number of \r\n sequences to be removed. I think that
> only one of these should be removed
> i.e. \r?\n
> Because of the context of the code there should not be any other \n but
> there can be any number of \r which should not be removed.
> This allows for the sending system to have used either \r\n (correct)
> or only \n (incorrect) as the line separator. MIME::Tools seems to be
> full of code that expects only \n to be generated or to be received.
- Let me explain what is happening.
First, the Reader uses \n as the line terminator, so there will not be
multiple \n in one line. Second, the entity boundary is \r\n, i.e.
this is the terminator that MIME adds to the end of the entity. Third,
there is a multi-part boundary that begins with two dashes -> '--'.
So, when the Reader encounters the multipart boundary, it then checks
the last line to see if ends with the \r\n (the entity boundary). If so,
it removes it. (Yes, it should only remove it once.)
It's pretty straight forward. If windows is sending a CRLF as \n\r,
then the last line is \r\r\n. The incorrect code removes everything.
The correct code just removes the \r\n.