Всё попиливаю клиент на common lisp, но столкнулся с некоторой странностью, объяснить которую я не могу. Если я пытаюсь отправить следующее сообщение

aWkudGVzdC4xNApBbGwKUmU6INCd0L7QstGL0LUg0Y3RhdC4INC90LAgc3RhdGlvbjEzCgrQotCw0LouINCa0YDQuNGC0LjRh9C10YHQutC40Lkg0LHQsNCzINGBINC+0YLQv9GA0LDQstC60L7QuSDQvNC90L7Qs9C+0YHRgtGA0L7Rh9C90YvRhSDRgdC+0L7QsdGJ0LXQvdC40LkgXl9fXgoK0K8sINGB0L7RgdCx0YLQstC10L3QvdC+LCDQt9Cw0LHRi9C7INGB0LrQsNC30LDRgtGMLCDRh9GC0L4g0LvQtdC90YLRgyDRgtC10L/QtdGA0Ywg0L3Rg9C20L3QviDRh9C40YLQsNGC0Ywg0YLRg9GCOiBpaTovL2xlbnRhLnJzcy4xNS4x

этим клиентом или просто через браузер на php-ноду, то сообщение доходит битым. Если 51talk использую, то всё нормально. С другой стороны, на python-ноду сообщения доходят нормально во всех случаях. Пробовал уже и так и эдак, но никаких идей не возникло.

>Я понял, в чём суть =)

>Как только я взял "тестовый образец" сообщения, то сразу заметил в нём слэш / и всё понял. Естесственно, протестировал его всеми методами (и оно портится в том же месте).

>> или просто через браузер на php-ноду
>Просто через браузер это всё происходило так, верно?
>ii-point.php?q=/u/point/<строка авторизации>/base64code

>Так вот: если base64-сообщение содержит слэши, то оно, естесственно, обрезается в запросе, так как нода принимает последующую часть за очередной параметр.

>Вариант 1 (самый оптимальный) - передавать через POST. Именно так поступает 51talk и остальные.

>Вариант 2 - использовать base64-urlsafe. Этот случай, кстати, прописан в документации ещё Ромой.

>> (если сообщение передавать через get-запрос, то оно там уже обязано быть base64_urlsafe)

>http://ii-net.tk/ii-doc/?p=4

?Также см. ii-functions.php line 80

>> С другой стороны, на python-ноду сообщения доходят нормально во всех случаях.
>Видимо, там стоит некий костыль, объединяющий все последующие параметры (при использовании /u/point/) в один. Но по правилам это нигде не прописано, и всегда использовали urlsafe.

Спасибо за помощь. Видимо, придётся использовать POST-запросом, так как cl-base64 не содержит необходимый функционал, а гугл ничего путного мне не подсказал пока.

Вот что жара со мной делает. Так всё просто, что мог бы и сам разобраться =)

> так как cl-base64 не содержит необходимый функционал, а гугл ничего путного мне не подсказал пока.
urlsafe же вроде не так сложен, как кажется на первый взгляд (поэтому можно самодельную функцию сделать). Ну а лично я всё равно бы порекомендовал POST, потому что так строку авторизации перехватить сложнее.

> Вот что жара со мной делает. Так всё просто, что мог бы и сам разобраться =)
Да ничего страшного. Тоже вот полусонный хожу последнее время =)

Кстати, твой txt-клиент с небольшой переделкой весьма успешно работает в связке с iissh. Вчера пробовал.
Так волнуюсь из-за него, потому что это sftp-транспорт - это решение архитектурной проблемы ii-http, а именно наличия возможности MITM.

Поступил ещё проще и разобрался таки с cl-base64. Вот не нашёл я по нему документации -- пришлось в исходник лезть. Благо common lisp прост и краток =)

Заборол я этот косяк своей поделки.

Я понял, в чём суть =)

Как только я взял "тестовый образец" сообщения, то сразу заметил в нём слэш / и всё понял. Естесственно, протестировал его всеми методами (и оно портится в том же месте).

> или просто через браузер на php-ноду
Просто через браузер это всё происходило так, верно?
ii-point.php?q=/u/point/<строка авторизации>/base64code

Так вот: если base64-сообщение содержит слэши, то оно, естесственно, обрезается в запросе, так как нода принимает последующую часть за очередной параметр.

Вариант 1 (самый оптимальный) - передавать через POST. Именно так поступает 51talk и остальные.

Вариант 2 - использовать base64-urlsafe. Этот случай, кстати, прописан в документации ещё Ромой.

> (если сообщение передавать через get-запрос, то оно там уже обязано быть base64_urlsafe)

http://ii-net.tk/ii-doc/?p=4

Также см. ii-functions.php line 80

> С другой стороны, на python-ноду сообщения доходят нормально во всех случаях.
Видимо, там стоит некий костыль, объединяющий все последующие параметры (при использовании /u/point/) в один. Но по правилам это нигде не прописано, и всегда использовали urlsafe.