[SR-Users] Kamailio accepts and stores XCAP XML document from jitsi but rejects it on retrieval

[Alex Villací­s Lasso]

El 30/05/14 11:02, Alex Villací­s Lasso escribió:
> El 29/05/14 12:15, Alex Villací­s Lasso escribió:
>> El 29/05/14 07:51, Daniel-Constantin Mierla escribió:
>>> Hello,
>>>
>>> the error message is printed in case of an invalid xml document.
>>>
>>> Can you edit modules/xcap_server/xcap_misc.c  and add inside function:
>>>
>>> int xcaps_check_doc_validity(str *doc)
>>>
>>> the log:
>>>
>>> LM_ERR("xmld document is: [[%.*s]]\n", doc->len, doc->s);
>>>
>>> before the line with:
>>>
>>> docxml = xmlParseMemory(doc->s, doc->len);
>>>
>>> Re-compile and re-install. Then run a test and send here the output of this line.
>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/xcap-caps/global/index
>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/xcap-caps/global/index
>> May 29 12:10:41 elx /usr/sbin/kamailio[17556]: ALERT: <script>: ===== xhttp: xcap-caps : <null>
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: request [HTTP/1.1] GET => /xcap-root/resource-lists/users/sip:avillacisIM at pbx.elastix.com/index
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ALERT: <script>: ===== xhttp: resource-lists : sip:avillacisIM at pbx.elastix.com
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_misc.c:690]: xcaps_check_doc_validity(): xmld document is: 
>> [[3C3F786D6C2076657273696F6E3D22312E302220656E636F64696E673D225554462D3822207374616E64616C6F6E653D226E6F223F3E3C7265736F757263652D6C6973747320786D6C6E733D2275726E3A696574663A706172616D733A786D6C3A6E733A7265736F757263652D6C69737473223E3C6C697374206E616D653D22526F6F7447726F7570223E3C656E747279207572693D227369703A626D6163696173407062782E656C61737469782E636F6D223E3C646973706C61792D6E616D653E626D61636961733C2F646973706C61792D6E616D653E3C2F656E7472793E3C2F6C6973743E3C2F7265736F757263652D6C697374733E]]
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_server.c:758]: xcaps_get_db_doc(): invalid xml doc retrieved from database
>> May 29 12:10:41 elx /usr/sbin/kamailio[17560]: ERROR: xcap_server [xcap_server.c:1171]: w_xcaps_get(): could not fetch xcap document
>>
>>
>> Huh....?
>>
>> The hex string happens to be an hex dump of the following:
>>
>> <?xml version="1.0" encoding="UTF-8" standalone="no"?><resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"><list name="RootGroup"><entry uri="sip:bmacias at pbx.elastix.com"><display-name>bmacias</display-name></entry></list></resource-lists>
>
> Looks like a SQL_C_BINARY is required somewhere. Right now I am trying to figure out where.
I worked this around by changing the column type to MEDIUMTEXT from the original MEDIUMBLOB:

ALTER TABLE xcap CHANGE COLUMN doc doc mediumtext not null;

Is this an acceptable solution? Could this cause issues with truly binary data stored there?

Now the table looks like this:

CREATE TABLE `xcap` (
   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
   `username` varchar(64) NOT NULL,
   `domain` varchar(64) NOT NULL,
   `doc` mediumtext NOT NULL,
   `doc_type` int(11) NOT NULL,
   `etag` varchar(64) NOT NULL,
   `source` int(11) NOT NULL,
   `doc_uri` varchar(255) NOT NULL,
   `port` int(11) NOT NULL,
   PRIMARY KEY (`id`),
   UNIQUE KEY `doc_uri_idx` (`doc_uri`),
   KEY `account_doc_type_idx` (`username`,`domain`,`doc_type`),
   KEY `account_doc_type_uri_idx` (`username`,`domain`,`doc_type`,`doc_uri`),
   KEY `account_doc_uri_idx` (`username`,`domain`,`doc_uri`)
) ENGINE=MyISAM AUTO_INCREMENT=7 DEFAULT CHARSET=latin1