64-битному libjingle не удалось проанализировать логин XML с ошибкой экспата: ERROR_INVALID_TOKEN
Только при попытке запустить мой логин под 64-битный, я получаю ошибку при входе в talk.google.com для моих начальных испытаний. 32-битный работает отлично.
После включения макросов ведения журнала и ведения журнала siginput я вижу, что XML-код, на котором происходит сбой, выглядит так:
<stream:stream from="gmail.com" id="3D9A4487B8514DE2" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\232\231\377
Внутри экспата я вижу, что есть XML_ERROR_INVALID_TOKEN меня бросают, но я не совсем уверен, куда идти дальше. Иногда он попадает в реальный логин, но вскоре умирает. Кажется, это относительно случайно, но всегда умирает в течение первых 10 ответов или около того. Я признаю, что ненужные данные в конце являются причиной неправильного токена, но я не уверен, что его вызывает.
Моя первоначальная мысль была проблема кодирования при переключении на 64-битный (??), но, честно говоря, я просто не знаю, что могло бы вызвать нечто подобное.
Вот дополнительный пример фрагмента из журналов, на которых умирает libjingle:
137[000:568] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:01:31 2013
[000:568] \332
[000:568] <iq id="2" type="result">
[000:568] <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
[000:568] <jid>
[000:568] [email protected]/CD6FF
[000:568] </jid>
[000:568] </bind>
[000:568] </iq>
<iq id="2" type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>[email protected]/CD6FF</jid></bind></iq>x\332Mhanism>X-OAUTH2</mechanism></mechanisms></stream:features>p
И другой:
[000:217] <stream:stream from="gmail.com" id="2462F624C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="246E4B24C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\225\231\377
Другая:
139[000:178] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:20:52 2013
[000:178] <stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\366\231\377
Другая:
52[000:243] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:23:44 2013
[000:243] Q
[000:243] <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>\261xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms></stream:features>Q
Кто-нибудь сталкивался с такой проблемой раньше?
Решение
при условии, что \ddd последовательности представляют восьмеричные числа, ваши потоки содержат кодовые точки в недействительном utf-8, который может быть ожидаемой кодировкой по умолчанию для потоков данных xml.
перед передачей содержимого в анализатор xml вам придется заменить ошибочные байты числовыми объектами, например, \231 -> ™,
другой вариант может заключаться в добавлении префикса вашего потока xml данных к прологу xml, объявляющему некоторый 8-битный набор символов, например. <?xml version="1.0" encoding="iso-8859-1" ?>,
надеюсь, что это помогает, с уважением
Другие решения
Похоже, это была проблема с 64-битной сборкой openssl, которую я использовал. Не знаю, что случилось со сборкой, но все, что мне нужно было сделать, — это переключиться на версии libssl.0.9.8 и libcrypto.0.9.8 dylib, и все отлично работает.
Надеюсь, это поможет другим диагностировать странный мусор во взаимодействиях SSL.