in reply to Re^2: Again on SOAP::Lite, MIME::Entity and SOAP::Packager
in thread Again on SOAP::Lite, MIME::Entity and SOAP::Packager

Looking at the source code of SOAP::Packager::MIME, the meat of it seems to be the sub ->package, which adds some headers to the MIME entity and after that calls $top->stringify_body;. So maybe the main trick is to use your own MIME::Entity subclass which has a better ->stringify_body:

package MIME::Entity::Ray;
use strict;
use parent 'MIME::Entity';
sub stringify_body {
    my( $self ) = @_;
    my $body = $self->SUPER::stringify_body();
    $body =~ s!\n!\r\n!g;
    return $body
};

[download]

And then instead of creating your own MIME::Entity objects create MIME::Entity::Ray objects instead.

If that still fails, maybe something else is creating MIME::Entity objects. Then either edit the source code or monkey patch MIME::Entity:

use MIME::Entity;
my $old_stringify_body = \&MIME::Entity::stringify_body;

*MIME::Entity::stringify_body = sub {
    my( $self ) = @_;
    my $body = $self->SUPER::stringify_body();
    $body =~ s!\n!\r\n!g;
    return $body
};

[download]

Update: After looking some more at SOAP::Packager, it even tries to do the Right Thing by setting:

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

[download]

except that MIME::Entity does not use that variable.

The real solution would be to make MIME::Entity use that variable.

Replies are listed 'Best First'.
Re^4: Again on SOAP::Lite, MIME::Entity and SOAP::Packager
by ray.rick.mini (Sexton) on Dec 28, 2016 at 15:16 UTC

    Update: Reply rewrote after several attempts.

    First: As you say, the module seems to ignore the variable it even if it is mentioned in the module changelog.

    I tried first solution, it is again not working. However, I cannot see any CRLF characters in the body section..and that is strange. Based on my test with curl, I suspect I should modify the boundary string of the main envelope section(see previous update) to add CRLF as exepcted by axis2 apache server. Of course I have no clue on how to do this in perl. That's why in the meanwhile I'm working on a simple sh implementation with the hardcoded request. I m unable to try your second suggestion it is actually, raising:

    Can't locate object method "stringify_body" via package "main::SUPER" at ./AR_Create.pl_ATTACHMENTS_WIP line 7.

    Here is the whole HTTP request with minimum CRLF characters expected by remote server I'm actually using with curl

    
This is a multi-part message in MIME format...

------------=_1482923885-24696-0^M
Content-Type: text/xml
Content-Disposition: inline
Content-Location: /main_envelope
Content-ID: <main_envelope>

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope 
..SOAP STUFF CUTTED OUT
</soap:Envelope>^M
------------=_1482923885-24696-0^M
Content-Type: application/octet-stream; name="uu.gif"
Content-Disposition: attachment; filename="uu.gif"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)

------------=_1482923885-24696-0--
GIF89a^P^@^P^@¢ÿ^@ÿÿÿ999kkkÂ~LÂ~LÂ~LÃ~@Ã~@Ã~@Ã~NÃ~NÃ~Nççç^@^@^
+@!ù^D^A^@^@^D^@,^@^@^@^@^P^@^P^@^@^CBHºÃ~\¾ã^U@k1±Ã~MJ'Ã~V\W^TDÂ
+¦laÂ| ^FÃ~L4^\pÂ¥^H-pÂ~DÂ~TA/.|s»^S^NX{Ã~EÂ~H<Ã~[^P^P$ôÂ~NÂ~U&j(]RÂ
+~Z%Â~Av»e-^R^@;
------------=_1482923885-24696-0--

    [download]

    This is the HTTP request that works. You may see where CRLF is expected. Surpisngly seems to be useful only in first multipart section, the one carrying SOAP request.3 damn characters are blocking my plan..LOL

[reply]
[d/l]
[select]

      Oh, sorry - I misled you in my untested reply about monkey patching. The monkeypatch should simply use $old_stringify_body. You now have the (IMO better) approach of patching the module directly, but for completeness, the following should allow you to replace just that subroutine:

      use MIME::Entity;
my $old_stringify_body = \&MIME::Entity::stringify_body;

*MIME::Entity::stringify_body = sub {
    my( $self ) = @_;
    my $body = $old_stringify_body();
    $body =~ s!\n!\r\n!g;
    return $body
};

      [download]
[reply]
[d/l]
[select]

        SUCCESS! Your code works great.. this actually fix the wrong behaviour: 

        my $old_stringify_body = \&MIME::Entity::stringify_body;

*MIME::Entity::stringify_body = sub {
    my( $self ) = @_;
    my $body = &$old_stringify_body;
    $body =~ s!\n!\r\n!g;
    return $body
};

        [download]
[reply]
[d/l]
Re^4: Again on SOAP::Lite, MIME::Entity and SOAP::Packager
by ray.rick.mini (Sexton) on Dec 29, 2016 at 09:42 UTC 
    diff --git a/usr/local/share/perl5/MIME/Entity.pm
b/usr/local/share/perl5/MIME/Entity.pm
index 3006853..ddfeb6c 100644
--- a/usr/local/share/perl5/MIME/Entity.pm
+++ b/usr/local/share/perl5/MIME/Entity.pm
@@ -1828,9 +1828,9 @@ sub print_body {
        ### Parts:
        my $part;
        foreach $part ($self->parts) {
-           $out->print("--$boundary\n");
+           $out->print("--$boundary\r\n");
            $part->print($out);
-           $out->print("\n");           ### needed for next delim/clo
+se
+           $out->print("\r\n");           ### needed for next delim/c
+lose
        }
        $out->print("--$boundary--\n");

    [download]

    I confirm the "bug" is in the print_body sub of MIME::Entity, in the part where it adds boundaries string to the body. I'm sure with the proposed patch will work with apache axis but peraphs will broke compatibility with other systems. What to do in those cases? Should I open a bug request somewhere?

[reply]
[d/l]

      I think a slightly more flexible approach would be to use $MIME::Entity::BOUNDARY_DELIMITER and set that to \r\n (if it's not set already). That way, people (still) using Apache Axis can configure their client to be compatible with that weird notion of line delimiters while the rest of the world can use \r\n as god intended.

      You can add that patch to rt://MIME::tools, possibly with a link back to this discussion and that other ticket mentioning the wrong kind of newlines being hardcoded. Even if the maintainer ignores that ticket+patch, at least others can find it there and apply it locally.

[reply]
[d/l]
[select]

        Here is the RT request:

        https://rt.cpan.org/Public/Bug/Display.html?id=119568

        Even if I successfully patched the module, I'm still convinced that I should monkey patch or extend it until I have an "official" resolution of the bug. Run a modified module breaks portability and updates, and I don't want to ship an additional file with my code. I ll retry with your solution in comment #3

[reply]

In Section Seekers of Perl Wisdom