HTTP::Headers Doesn't like SOAP::Lite fields named "APR::Table=HASH(0x7f7929552af0)" [rt.cpan.org #84461]

[oalders]

Migrated from rt.cpan.org#84461 (status was 'new')

Requestors:

• david@justatheory.com

Attachments:

• smime.p7s

From david@justatheory.com on 2013-04-06 05:06:02:

Started getting errors like this from SOAP::Lite recently:

[Sat Apr 06 04:52:16 2013] [error] Error executing SOAP command: Illegal field name 'APR::Table=HASH(0x7f7929552af0)' at /usr/local/share/perl5/SOAP/Transport/HTTP.pm line 818\n

This is caused by this change in HTTP-Headers 6.05:

> 2012-10-20 HTTP-Message 6.05
> 
> Gisle Aas (5):
>       Updated ignores
>       No need to prevent visiting field values starting with '_'
>       Report the correct croak caller for delegated methods
>       Disallow empty field names or field names containing ':'
>       Make the extra std_case entries local to each header

I fixed it by downgrading HTTP::Messages, but the real question is: should field names defined as objects actually be allowed? Or is this a bug in SOAP::Lite?

Thanks,

David

[theory]

2013!

[oalders]

Let's come to an agreement that if this is still open in 2021 we'll move it to yet another bug tracker. ;)

Would you happen to know if this is still an issue? There was so much accumulated stuff in RT and we're very slowly trying to chip away at it.

[theory]

I have NFI. There have been a lot of changes to SOAP-Lite since April 2013, so maybe they worked around it or fixed it on their end?

If not, I imagine if we do a new test of our SOAP server with updated RPMs I'll see it again. Dunno when or if that will happen.

[genio]

@redhotpenguin Have you noticed this in any of your testing?

[mxroo]

I use OCS Inventory, and followed a bug trail that led me here and I can confirm that there is still an issue in HTTP::Message 6.13 on Debian. I tried version 6.06 first, and then upgraded to 6.13.

Error:
[Thu Aug 10 11:33:14.794945 2017] [perl:error] [pid 7764] [client 50.116.51.171:36188] Illegal field name 'APR::Table=HASH(0x57e1e040)' at /usr/local/share/perl/5.20.2/SOAP/Transport/HTTP2.pm line 103.\n

 # cpan -D HTTP::Message
Loading internal null logger. Install Log::Log4perl for logging messages
Reading '/root/.cpan/Metadata'
  Database was generated on Thu, 10 Aug 2017 08:41:02 GMT
HTTP::Message
-------------------------------------------------------------------------
	(no description)
	O/OA/OALDERS/HTTP-Message-6.13.tar.gz
	/usr/local/share/perl/5.20.2/HTTP/Message.pm
	Installed: 6.13
	CPAN:      6.13  up to date
	Gisle Aas (GAAS)
	gisle@ActiveState.com

bug trail:
https://stackoverflow.com/questions/36751458/enabling-ocs-inventory-webservice-interface-for-querying-assets-data
https://www.tnpi.net/support/forums/index.php?topic=1037.0
https://rt.cpan.org/Public/Bug/Display.html?id=84461

[oalders]

The StackOverflow thread mentions installing 6.04 Are you able to test this with 6.05? I'd be interested to know if we can exactly pin down the version which introduces this problem.

[oalders]

Ah, just re-read the original comment. It looks like this did break in 6.05

[mxroo]

Would you still like me to try to test with 6.04 or 6.05?

[oalders]

@mxroo I'm not sure we need to test that out now. The diff is here https://metacpan.org/diff/file?target=GAAS%2FHTTP-Message-6.05%2F&source=GAAS%2FHTTP-Message-6.04

[oalders]

Is this the culprit? 5aaa8144

[mxroo]

Yup, sure looks like it to me.

[genio]

@mxroo Can you provide the actual XML it's trying to parse when the error occurs? (if it's a huge thing, cutting it down to the least amount of XML possible would be great.)

Thanks!

[mxroo]

Here is the php script I was trying to run.
copied directly from https://stackoverflow.com/questions/36751458/enabling-ocs-inventory-webservice-interface-for-querying-assets-data

<?php
$proto = 'https';
$host = 'hq.palantetech.coop';
$port = '443';
$user = 'jamila'; //basic authentication, if necessary
$pass = "XXXXXX"; 

$options = array(
    'location' => "$proto://$host:$port/ocsinterface",
    'uri' => "$proto://$host:$port/Apache/Ocsinventory/Interface",
    'login' => $user,
    'password' => $pass,
    'trace' => TRUE,
    'soap_version' => SOAP_1_1,
);

$request = '
        <REQUEST>
            <ENGINE>FIRST</ENGINE>
            <ASKING_FOR>INVENTORY</ASKING_FOR>
            <CHECKSUM>131071</CHECKSUM>
            <OFFSET>0</OFFSET>
            <WANTED>131071</WANTED>
        </REQUEST>';

try {
    $client = new SoapClient(NULL, $options);
} catch (Exception $e) {
    echo "<b>Construct Error</b>: " . $e->getMessage() . "<br>";
}

try {
    $result = $client->get_computers_V1($request);
    echo "<b>Headers:</b><pre>" . $client->__getLastRequestHeaders() . " </pre><br>";
    echo "<b>Request:</b><pre>" . $client->__getLastRequest() . "</pre><br>";
    echo "<b>Result:</b><pre>";
    var_dump($result);
    echo "</pre><br>";
} catch (Exception $e) {
    echo "<b>Connection Error</b>: " . $e->getMessage() . "<br><br>";
    echo "<b>Headers:</b><pre>\r\n" . $client->__getLastRequestHeaders() . " </pre><br>";
echo "<b>Request:</b><pre>\r\n" . $client->__getLastRequest() . "</pre>";
}

[oalders]

@redhotpenguin any thoughts as to how to proceed here?

[karenetheridge]

This is a bug in SOAP::Lite that apparently hasn't been noticed until HTTP::Message got strict enough to expose it. We (someone) should try to figure out where those headers are coming from and determine the actual intent. I would suggest looking at the full stack trace of the error that HTTP::Message gives, to find the place in SOAP::Lite that is creating the headers.

[mxroo]

Let me know if there is any other information I can provide to help on this issue. Thanks!

[oalders]

@mxroo are you able to get at the underlying server code in order to get some debugging info?

[mxroo]

@oalders Probably, I have full root on all of my servers. What debugging information would help?

[karenetheridge]

@mxroo

@mxroo Can you provide the actual XML it's trying to parse when the error occurs? (if it's a huge thing, cutting it down to the least amount of XML possible would be great.)

This is a bug in SOAP::Lite that apparently hasn't been noticed until HTTP::Message got strict enough to expose it. We (someone) should try to figure out where those headers are coming from and determine the actual intent. I would suggest looking at the full stack trace of the error that HTTP::Message gives, to find the place in SOAP::Lite that is creating the headers.

[oalders]

@mxroo if you need any tips on getting at the XML and dumping it, we can help with that.

[mxroo]

Tips would be very helpful, thank you!

[oalders]

@mxroo to get a better stack trace you could try adding a use Devel::Confess; to the server software which parses the XML. If you can't find the right place, you can also temporarily hack it into HTTP::Message. That should give us a better idea of the call stack. You may need to install Devel::Confess as well.

[oalders]

Since this is mod_perl you'll need to restart Apache (or possibly reload -- it has been a while for me).

[mxroo]

Does this help?
I installed Devel::Confess, found a perl script to query the api and then added use Devel::Confess; to it.

500 Internal Server Error at /usr/share/perl5/SOAP/Lite.pm line 3613.
        SOAP::Lite::__ANON__(SOAP::Lite=HASH(0x8537a34), "\x{a}syntax error at line 1, column 49, byte 49 at /usr/lib/i386-"...) called at /usr/share/perl5/SOAP/Lite.pm line 3801
        SOAP::Lite::call(SOAP::Lite=HASH(0x8537a34), "get_computers_V1", "\x{a}<REQUEST>\x{a}  <ENGINE>FIRST</ENGINE>\x{a}  <ASKING_FOR>META</ASKIN"...) called at /usr/share/perl5/SOAP/Lite.pm line 3761
        SOAP::Lite::__ANON__(SOAP::Lite=HASH(0x8537a34), "\x{a}<REQUEST>\x{a}  <ENGINE>FIRST</ENGINE>\x{a}  <ASKING_FOR>META</ASKIN"...) called at ./ocssoap.perl line 74

[oalders]

This seems to be a different error. Can you validate that the XML you're trying to send is correct?

[mxroo]

I'm not as fluent in XML, but it seems like the XML that that script is asking for is this:

<REQUEST>
  <ENGINE>FIRST</ENGINE>
  <ASKING_FOR>META</ASKING_FOR>
  <CHECKSUM>131071</CHECKSUM>
  <OFFSET>0</OFFSET>
  <WANTED>131071</WANTED>
</REQUEST>

from the bottom of this page: http://wiki.ocsinventory-ng.org/index.php?title=Developers:Web_services

I got the exact same error in the apache logs when doing that.

[mxroo]

Is that the XML that is needed, or am I misunderstanding? I can try again.