Re: SOAP::Lite or MIME::Entity generate invalid HTTP line endings

[bellaire]

Are you using a recent version of SOAP::Lite? It looks like the authors have gone to a lot of trouble to make sure that CRLF is used properly where it's needed. In particular, the most recent copy of the source is definitely reaching into the guts of MIME::Entity to set the boundary delimiter, e.g. in SOAP::Lite::Packager at line 146:

local $MIME::Entity::BOUNDARY_DELIMITER = "\r\n";

You can probably try this in your own code if for some reason SOAP::Lite isn't, to make sure that your MIME encodings have the proper line endings.

[almut]

The strange thing is that this $MIME::Entity::BOUNDARY_DELIMITER variable isn't being used in MIME::Entity (or anywhere else in the entire MIME-tools package).  In other words, setting it presumably has no effect...

...despite this entry in SOAP::Lite's Changes file:

0.60 Mon Aug 18 12:10:27 2003
  ...
  ! Fixed MIME interoperability bug with Apache Axis - Axis' MIME
    parser requires that MIME boundaries are terminiated by a CRLF
    character where the MIME::Tools package only outputs a CR
    character. A patch was integrated into the MIME::Tools module
    which allows SOAP::Lite to specify its own MIME Boundary delimiter

[Tardigrade4]

Thank you for replying.

To be more specific, it is only when I try SOAP with attachments that Axis2 fails to find the \r\n sequence. Normal RPC works nicely. However, I know for a fact that somebody left off a \r, but only when packaging the parts for SOAP with attachments.

It seems that the bad data is coming from MIME::Entity, which does not use the BOUNDARY_DELIMITER you mention, and has 29 \n characters. Perhaps all of these are illegal.

My client's expectation is to be able to "perl -MCPAN -e shell" and "install" . I'm new to perl and I would not trust myself to fix something like this (nor would you want me to :-)) , nor would my client expect to pay me to do this. I also am not aware of how ownership of modules works.

It would be nice to pass along the message.

It does not look like I'll be doing attachments.