import xmlobjects
import psycopg2

xml = """

   user
password
   dbname

"""

conf = xmlobjects.fromstring(xml)
conn = psycopg2.connect('dbname=%s user=%s password=%s' % (
    conf.db.dbname, conf.db.user, conf.db.password))


(HttpInvalidParamException) Empty or too short HTTP message: ''


Понятное дело, для отладки они не подходят. Но, если вывести исключение полностью, то обычно там как-раз и были подробности проблемы:


exception 'HttpInvalidParamException' with message 'Empty or too short HTTP message: ''' in example.php:189 inner exception 'HttpRequestException' with message 'Timeout was reached; Operation timed out after 10000 milliseconds with 0 bytes received (https://example.ru/)' in example.php:160


Видно, что самое важное содержится в сообщении от inner exception. И его, оказывается, легко поймать, если поставить дополнительный блок catch на HTTPException, например:

try {
    $request->send();
} catch (HttpException $ex) {
    if (isset($ex->innerException)){
        echo $ex->innerException->getMessage();
        exit;
    } else {
        echo $ex;
        exit;
    }
}

Информация получена отсюда.

Сама суть механизма подписи хорошо описана в этой статье, из которой и я почерпнул для себя несколько полезных моментов, на которых возник ступор поначалу. Но предлагаемый мной вариант имеет одно важное дополнение: он добавляет в SOAP-сообщение ещё и информацию о сертификате, с помощью которого была сделана подпись. Кстати, меня удивила логика одной системы, для которой это делалось (кстати, написанной на Microsoft’овских компонентах): помимо сертификата в SSL-соединении они ещё проверяли сертификат и в самом запросе, хотя могли бы и воспользоваться данными HTTPS и тем самым получить ещё дополнительную проверку того, что соединение открыто тем самым агентом, который подписывал запрос.

Основным моментом в подписи является то, что собираются хэши (дайджесты) узлов с данными, которые будут подписаны (при этом узлы приводятся в канонический вид с помощью утилиты xmllint из комплекта libxml2). После чего собранные внутри одной «обёртки» дайджесты подписываются ключом сертификата, тем самым гарантируя, что если подпись верна, то данные в этих узлах не были изменены во время передачи запроса.

Класс так-же переписывает механизм HTTP-запроса к удалённому серверу, т.к. даже с помощью stream_context PHP не позволяет использовать совместно с SOAP сертификаты в формате PKCS12. В итоге используется HTTPRequest, результат которого уже транслируется далее в обработку.

• Собственно сам класс: SignedSoapClient.zip

Кстати, у Blogger’а выяснилась пара забавных моментов. Первый – это то, он строго следует спецификациям Atom при создании и редактировании сообщений. Но при этом, если отправлять ему содержимое поста с типом xhtml, завернутое в <div xmlns="http://www.w3.org/1999/xhtml">...</div>, то назад он возвращает содержимое завёрнутое как html, но при этом сохраняет этот самый div. Логика загадочна для меня.

Второй момент ещё более непонятный: по ходу тестирования я делал пачки постингов в блог. В какой-то момент получилось так, что пост проходит, возвращается назад с присвоенным id и т.п., а в блоге не появляется. Никаких намёков на то, почему так, нет. Буду пробовать дальше

Дополнение: всё оказалось очень просто. Из-за кучи постингов во время тестов blogger включил для моего аккаунта требование вводить captcha перед каждым постом. По сути можно было написать в блог только через веб-форму. Налицо явная недоработка API, так как ошибку внятную можно было и вернуть.