Re: Again on SOAP::Lite, MIME::Entity and SOAP::Packager

[Corion]

I think the reply in SOAP::Lite or MIME::Entity generate invalid HTTP line endings pointing out that MIME::Entity uses hardcoded \n in various places and has old bugs pertaining to newlines, the simplest approach would be to clone MIME::Entity and replace all \n by \r\n (hardcoded) in its source code.

The less intrusive and far more hacky solution is to post-process the output of MIME::Entity yourself:

open my $output_fh, '>', \my $mime_body
    or die "In-memory handles are not supported by your version of Per
+l.";
$mime->print( $output_fh );
close $output_fh;
$mime_body =~ s!\n!\r\n!g;
# use $mime_body as the string wherever you would use it with SOAP::Pa
+ckager
# I don't know if the following is valid, using a raw string as a MIME
+ part:
$soap->parts( [$mime_body] );

Maybe you need to mock up a MIME::Entity::NewlineFixed instead which implements just enough of the MIME::Entity interface to make SOAP::Packager happy, but I don't know which parts SOAP::Packager uses.

[ray.rick.mini]

Unluckily, your suggestion doesn't seems to work. I managed to substitute chars, but parts() method starts complaining for the raw string, as you already guessed in your comments. That's why I tried to modify as following:

..
print Dumper \$ent;

my $aref=[];
my $oldr=$ent->{mail_inet_head}->{mail_hdr_list};
foreach (@$oldr){
  my $n=$_;
  $n=~s/\n/\r\n/g;
  push(@$aref,$n);
}

$ent->{mail_inet_head}->{mail_hdr_list}=$aref;
#       exit;

my $result = SOAP::Lite
          ->packager(SOAP::Packager::MIME->new)
          ->parts([$ent])
          ->proxy($create_proxy, ssl_opts => [ SSL_verify_mode => 1, S
+SL_ca_file => '/root/Firefox_CERT/CUSTOMERROOTCA2'] )
          ->call($header, $method => @data)
;

This actually override \n in header section, but the request is still not accepted by remote server throwing a 500 error. I'm still confused because MIME::Entity is only building a little block of the final HTTP request (the encoded binary file with his headers), I guess SOAP::Packager is adding lot of things like multipart etc. I'll try to deepen with curl changing only 1 row at a time to see which section of the request is causing the behaviour. In the meanwhile, suggestions are welcome

[Corion]

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
};

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
};

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";

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

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

[ray.rick.mini]

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--

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

[ray.rick.mini]

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");

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?