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

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

Replies are listed 'Best First'.
Re^5: Again on SOAP::Lite, MIME::Entity and SOAP::Packager
by Corion (Patriarch) on Dec 29, 2016 at 09:50 UTC

    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]

        Thanks for confirming this. I'm not sure whether patching ->stringify_body is the best approach in general. I've looked through the test suite and the test suite caters in various locations for output being different sizes depending on whether Perl uses \n or \r\n when writing text files without binmode. This makes me feel that the whole test suite would also need an overhaul together with the module to produce identical output regardless of where it is run.

        As I don't have a (direct) use case for MIME::tools beyond MIME::Parser and thus don't know what the applicable RFCs say, it's hard to tell (and fix) the situations where \n is used wrongly. Hopefully your investigations and findings here help others encountering SOAP problems address these issues.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom