Loading ...
Sorry, an error occurred while loading the content.

4120Re: [soaplite] Re: Possible bug in handling MIME messsage?

Expand Messages
  • Byrne Reese
    Oct 26, 2004
      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
      his opinion.

      =-D

      Byrne

      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)/);
      > Indeed.
      > 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
      >
      > \r\n
      > \n
      >
      > 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.
      >
      > Regards
      > Duncan
      >
    • Show all 11 messages in this topic