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

Re: Possible bug in handling MIME messsage?

Expand Messages
  • herwighenseler
    Hi, thanks for the responses so far. Yes, i tried with base64 encoding and yes, it worked. The trailing n was preserved. ... This could be the root of the
    Message 1 of 11 , Oct 26, 2004
    • 0 Attachment
      Hi,

      thanks for the responses so far. Yes, i tried with "base64" encoding and yes, it worked.
      The trailing \n was preserved.

      --- In soaplite@yahoogroups.com, "jpeyser" <jpeyser@p...> wrote:
      > The SOAP::Packager::MIME package defaults the mime_encoding to '8bit'
      >
      > This has to be overridden with something like
      >
      > $soap->packager->{_content_encoding} = 'binary';

      This could be the root of the problem. Although I encoded my part with "binary"
      (explicitly), the full MIME message seems to be encoded with "8-bit", causing problems.
      Well, it should work since different parts of the message should be able to contain
      different encoding messages, but I guess here is the problem. Still not sure if it's SOAP's
      fault or MIME's.

      I can't see how the last line should change the behaviour of the packager since
      _content_encoding isn't used anywhere in SOAP::LIte. Aer you referring to SOAP::Lite 0,65
      beta? (I'm using 0.60a).

      Herwig
    • jpeyser
      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
      Message 2 of 11 , Oct 26, 2004
      • 0 Attachment
        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)/);

        Jonathan
      • 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 3 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 4 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 5 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.