in reply to Re^2: Soap::Lite - returning lots of info
in thread Soap::Lite - returning lots of info

Chances are good that Im doing something ignorant here.
Unfortunately, I think chances are better that there's some serialisation bug in SOAP::Lite ;)

Obviously the size of the data-structure should have no impact on serialisation. If you've tested at just below and just above 0x3FFF and can repeat the result, then report a bug. There are many 1+ year old bugs there so I don't know whether that will help, but documenting the bug can't hurt.

The serialisation classes don't look too complicated... you may wish to have a go at debugging this yourself.

Martin Kutter would seem to be the active maintainer (someone please correct me if necessary), so you could probably direct any questions (which get raised in tracking it down yourself) to him. Martin wrote SOAP::WSDL (one of my favourite modules) which takes the hassle out of the client-side... I'm pretty sure he understands the SOAP::Lite codebase well ;)

-David

  • Comment on Re^3: Soap::Lite - returning lots of info

Replies are listed 'Best First'.
Re^4: Soap::Lite - returning lots of info
by ethrbunny (Monk) on Oct 22, 2007 at 15:13 UTC
    The worm has turned..

    In order to make a 'clean' repro case I started pruning the code down to its most essential form. One thing I took out was the https: wrapper that I was using (HTTP::Daemon::SSL). The truncation issue has gone away!

    Im looking at the return value(s) from my test package before it hits the 'send_response' and its intact.

    Now Im digging into the docs for the SSL wrapper.

    Further: it appears to be solely contingent on the SSL portion. If I wrap my SOAP package in HTTP::Daemon it works fine. Adding the ::SSL causes the fault.

    Now I need to see if this is 'by design'.

    EDIT: at this point Im guessing that because my client is sending the 'HTTP1.1' header the return value is getting sliced up. From the docs for HTTP::Daemon
    If the client is HTTP/1.1 aware then we will use chunked transfer encoding for the response.
      Addendum: I was able to see my return values being chopped into 0x3FFF pieces prior to being returned. Unf I was unable (given my time constraints) to figure out how to trap this situation on the client so that I could recombine the resultant parts prior to marshaling them back into my hash.

      Im guessing that the 'chunked transfer' is what's happening as I do see the 'HTTP1.1' header being sent.

      At this point its easier for me to restructure my server code to send smaller increments of data than to disassemble SOAP::Lite to get what I need from it. Its not the ideal solution but it will have to suffice for now.