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

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

Expand Messages
  • Duncan Cameron
    ... 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
    Message 1 of 11 , Oct 26, 2004
    • 0 Attachment
      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
    • Byrne Reese
      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
      Message 2 of 11 , Oct 26, 2004
      • 0 Attachment
        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
        >
      • jpeyser
        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
        Message 3 of 11 , Oct 26, 2004
        • 0 Attachment
          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.

          Jonathan
        Your message has been successfully submitted and would be delivered to recipients shortly.