Обнаружил на сабже одно порченное сообщение в ii.test.14 ii://FbYeDw3FpA64o9g2ga20
Самое интересное не это, а то, что на моих станциях оно отсутствует вопреки блэклисту (и фетчер не давал ни единого предупреждения, что его не пускает).

Ещё более странное дело с /x/file. Подключившись к Таверне через свой клиент, обнаруживаю, что не могу получить список файлов.
Провернув небольшой дебаг, выяснил, что нода даёт пустой ответ. Подумав, что косяк на моей стороне (CutieFeed), проделываю аналогичный запрос через Curl:

curl --data-binary "pauth=my_authstr" http://idec.spline-online.tk/x/file

и получаю ... пустую строку, хотя по идее здесь должен был быть список файлов. Если добавить параметр filename, то всё работает.

curl --data-binary "pauth=my_authstr&filename=ic_robot.jpg" http://idec.spline-online.tk/x/file
# содержимое файла

Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть), но при этом при запросе /x/file/random_string/filename нода шлёт пустоту, хотя файл публичный. При неверном authstr нода должна запретить вывод скрытого файла, но не публичного.

Такие вот дела.

vit01> Обнаружил на сабже одно порченное сообщение в ii.test.14 ii://FbYeDw3FpA64o9g2ga20

Спасибо. Посмотрю.

vit01> Ещё более странное дело с /x/file. Подключившись к Таверне через свой клиент, обнаруживаю, что не могу получить список файлов.

vit01> и получаю ... пустую строку, хотя по идее здесь должен был быть список файлов. Если добавить параметр filename, то всё работает.

Что странно, так как я спокойно его получаю. Надо будет снаружи проверить, но это только в среду смогу.

vit01> Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть)

Вот тут поподробней. Судя по стандарту он так и должен себя вести в случае с публичным файлом.

vit01> но при этом при запросе /x/file/random_string/filename нода шлёт пустоту, хотя файл публичный. При неверном authstr нода должна запретить вывод скрытого файла, но не публичного.

Вот это тоже неоднозначная ситуация, но можно и предложенное тобой поведение добавить.

vit01> Такие вот дела.

ЗЫЖ Таверна это вообще загадочное место. Иногда здесь случаются поистинне мистические вещи.

vit01> Самое интересное не это, а то, что на моих станциях оно отсутствует вопреки блэклисту (и фетчер не давал ни единого предупреждения, что его не пускает).

Забавное дело. Если сделать запрос на таверну в вот таком формате, как делает мой фетчер:

http://idec.spline-online.tk/u/e/game.rogue.14/ru.humor.14/lor-opennet.15/linux.14/ii.test.14/lit.14/pipe.2032/ii.14/habra.16/mlp.15/ifiction.15/piratemedia.rss.15/lenta.rss/python.15/creepy.14/develop.16/edgar.allan.poe/ii.stat/-200:200

, то этого странного айдишника в списке нет.

Если же убрать из запроса эху game.rogue.14, то он вдруг появляется. Тьфу, чёрная магия какая-то.

# на предыдущем сообщении, на которое сейчас отвечаю, регулярки веб-интерфейса таверны сломались

vit01> # на предыдущем сообщении, на которое сейчас отвечаю, регулярки веб-интерфейса таверны сломались

Вот это уже пофиксил. С остальным пока не могу разобраться.

AL> А как быть, если у пользователя отсутствует поинт на ноде? Не надо забывать про GET-запросы всё таки.

На этот случай тоже всё предусмотрено. "Собаку съел" на /x/file, что называется.
Возьмём, к примеру, сообщение из пайпа про фоточки с прогулки: ( ii://flYdgHRQTACMOc9kW4KW )

vit01> Если что, вот браузерная ссылка: http://ii-net.tk/ii/ii-point.php?q=/x/file/none/2016-04-16.tar.xz

Когда человек запрашивает публичный файл (даже не являясь поинтом), то он имеет право ставить в поле authstr всё, что захочет. В данном случае стоит "none", но можно хоть "blablabla" поставить, и mira station всё равно отдаст файл. Если файл публичный, то нода authstr просто не будет проверять.

AL> Только сперва таки надо разобраться что пользователь должен слать в GET-запрос.

Можешь алгоритм посмотреть: https://github.com/vit1-irk/ii-php/blob/master/ii-point.php#L167

vit01>> Это не первая странность с /x/file. Проверив через браузер, обнаруживаю, что при запросе /x/file/filename выдаётся содержимое файла (хотя по стандарту так не должно быть)

AL> Вот тут поподробней. Судя по стандарту он так и должен себя вести в случае с публичным файлом.

Неа. Судя по стандарту, третьим параметром всегда должна идти authstr.
Цитата http://ii-net.tk/idec-doc/?p=extensions

> POST /x/file или GET /x/file/pauth/filename
> Параметры в теле запроса: pauth и filename. pauth - строка авторизации, filename - имя скачиваемого файла.

> Если filename отсутствует, то выдаёт список публично доступных файлов в формате <Имя>:<размер в байтах>:<Описание>. Если параметр pauth верный (существует поинт с таким паролем), то добавляет к "публичному" списку также скрытые от посторонних глаз файлы.

Если человек сделал запрос /x/file/string, то нода должна проверить правильность authstr и вывести на экран список файлов, причём не только публичных, но и "приватных".

Мы же при формировании стандарта договорились сделать возможность размещать как файлы только для поинтов, так и файлы для всех остальных.

AL> Что странно, так как я спокойно его получаю. Надо будет снаружи проверить, но это только в среду смогу.

Через ту самую curl-команду, что я написал?

CutieFeed работает c /x/file исключительно через POST-запросы, так что вполне может быть, что конкретно твои скрипты работают (если они под GET заточены).

AL> Лично я, когда предлагал эту схему, предполагал переменное количество параметров в зависимости от того, что пользователь передаёт. Чтобы хоть wget'ом, хоть через браузер мог быстро и понятно получить файлы.

А так разве медленно и непонятно? При нынешнем подходе оно хотя бы работает и выполняет поставленные задачи.
Можно поменять местами pauth и filename, но в таком случае будет неудобно получать список файлов.

vit01> Неа. Судя по стандарту, третьим параметром всегда должна идти authstr.

vit01> Если человек сделал запрос /x/file/string, то нода должна проверить правильность authstr и вывести на экран список файлов, причём не только публичных, но и "приватных".

vit01> Мы же при формировании стандарта договорились сделать возможность размещать как файлы только для поинтов, так и файлы для всех остальных.

А как быть, если у пользователя отсутствует поинт на ноде? Не надо забывать про GET-запросы всё таки.

Я сейчас туда заглянул и ужаснулся. x/file надо переделывать с нуля, можно сказать. Что-то я там такую чушь наворотил. Только сперва таки надо разобраться что пользователь должен слать в GET-запрос.

vit01> А так разве медленно и непонятно? При нынешнем подходе оно хотя бы работает и выполняет поставленные задачи.

Ну так и без расширенной u/e оно хотя бы работало. И выполняло поставленные задачи. Надо думать об удобстве.

vit01> Можно поменять местами pauth и filename, но в таком случае будет неудобно получать список файлов.

Да там одно простое условие. Просто я писал как всегда перед сном и потому там лажа у меня в коде. Но я не настаиваю. Стандартом по факту занимаешься ты. Если считаешь, что надо всегда указывать authkey, даже если его нет, то сделаем так. Просто я и так и этак смотрю на такой подход, а он мне всё равно не нравится.

Пожалуй, сделаю пробно в таверне то, о чём я говорю, а ты посмотришь. Если не понравится, то сделаю с обязательной авторизацией.

vit01> Возьмём, к примеру, сообщение из пайпа про фоточки с прогулки: ( ii://flYdgHRQTACMOc9kW4KW )

vit01>> Если что, вот браузерная ссылка: http://ii-net.tk/ii/ii-point.php?q=/x/file/none/2016-04-16.tar.xz

vit01> Когда человек запрашивает публичный файл (даже не являясь поинтом), то он имеет право ставить в поле authstr всё, что захочет. В данном случае стоит "none", но можно хоть "blablabla" поставить, и mira station всё равно отдаст файл. Если файл публичный, то нода authstr просто не будет проверять.

Твою точку зрения я понял, но мне она не кажется так уж хорошей. Поведение должно быть такое, чтобы человек интуитивно мог составить ссылку.

Лично я, когда предлагал эту схему, предполагал переменное количество параметров в зависимости от того, что пользователь передаёт. Чтобы хоть wget'ом, хоть через браузер мог быстро и понятно получить файлы.

// Я ещё подумаю, а пока x/file в таверне можете считать нерабочей.

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

Сделал в таверне такой вариант. Попробовал его и с GET и с POST запросами. Понравилось. Пока из всего, что мы надумали, этот вариант мне нравится более всего.

vit01> Проблема в том, что нода должна как-то различать authstr и имя файла. Вот отправил ты запрос /x/file/string, а нода должна думать: ты поинт и хочешь получить список, или ты файл с именем string скачать хочешь? Забавные вещи будут выходить, если в конфиге есть и файл с таким названием, и поинт с таким authstr.

Вероятность того, что authkey будет хотя бы напоминать имя ркального файла болтается где-то в районе нуля. У нас и коллизии в msgid могут запросто возникнуть, но с исчезающе малой вероятностью. Потому я считаю, что простой проверки по поинтлисту достаточно, чтобы определить что это пользователь передал.

vit01> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

vit01> ====
vit01> GET /x/filelist
vit01> # публичные файлы

vit01> GET /x/filelist/pauth
vit01> # публичные + приватные файлы, если authstr верный

vit01> GET /x/file/filename
vit01> # публичный файл или ошибка

vit01> GET /x/file/pauth/filename
vit01> # приватный (или публичный) файл или ошибка, различие
vit01> # с предыдущим запросом определяется по количеству параметров
vit01> ====

Вот такой вариант стройнее и красивее. И надо решать вопрос пока ещё этой фичи толком нет нигде.

vit01> Да к чёрту этот авторитет. Мы же технические вопросы обсуждаем, а здесь такие нелепости никакого значения не имеют.

Я тут понял на примере того же инстеда, что разработка стандарта должна опираться на два столпа: непротиворичивость и диктаторства. Иначе начнётся элементарный хаос. Потому я и признаю авторитет, потому и мусолю эту тему с файлами так муторно.

vit01> Так изменяем или не изменяем саму схему? Вообще, POST у тебя точно сломанный, а насчёт GET надо сейчас до конца решить.

Я сегодня постараюсь найти время на исправление ноды.

AL> Видимо, у нас разное представление о "прекрасном" просто. Мне нравится идея, что третий параметр может быть или authkey или именем файла и нода в зависимости от этого отдаёт соответствующую информацию.

Проблема в том, что нода должна как-то различать authstr и имя файла. Вот отправил ты запрос /x/file/string, а нода должна думать: ты поинт и хочешь получить список, или ты файл с именем string скачать хочешь? Забавные вещи будут выходить, если в конфиге есть и файл с таким названием, и поинт с таким authstr.

Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

GET /x/filelist
# публичные файлы

GET /x/filelist/pauth
# публичные + приватные файлы, если authstr верный

GET /x/file/filename
# публичный файл или ошибка

GET /x/file/pauth/filename
# приватный (или публичный) файл или ошибка, различие
# с предыдущим запросом определяется по количеству параметров

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

Да к чёрту этот авторитет. Мы же технические вопросы обсуждаем, а здесь такие нелепости никакого значения не имеют.

AL> Просто пропиши этот момент в стандарт более однозначно, а я уж буду им руководствоваться при правке своей ноды.

Так изменяем или не изменяем саму схему? Вообще, POST у тебя точно сломанный, а насчёт GET надо сейчас до конца решить.

vit01> Ну а что бы ты предложил в альтернативу? Тут два варианта: либо GET-запросы не работают с приватными файлами, либо оно выглядит "некрасиво".

Видимо, у нас разное представление о "прекрасном" просто. Мне нравится идея, что третий параметр может быть или authkey или именем файла и нода в зависимости от этого отдаёт соответствующую информацию.

vit01> Мне-то всё равно, у меня клиент в любом случае работает только через POST (а кроме нас двоих сабжем в принципе никто не пользуется), так что пробуй, решай, как удобнее будет.

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

vit01> Дело здесь не в самих ошибках в коде и коллизиях. Суть в костылях, которые надо нагромождать в исходниках, чтобы заставить это работать. Причём на разных нодах они могут приводить к разному поведению, и это очень неудобно.

Просто смотря от чего плясать. Я стараюсь от удобства пользователя, хотя по большей части для этого есть скрипт и пользователю должно быть до лампочки.

vit01> Насчёт POST прошу уточнить, т.к. это важно. Мы делаем примерно такой вариант?

vit01> ====
vit01> POST /x/filelist
vit01> # публичный список

vit01> POST /x/filelist pauth=string
vit01> # приватный + публичный список, либо только публичный, если неверно

vit01> POST /x/file pauth=string, filename=string2
vit01> # содержимое файла, если pauth верный или filename публичный
vit01> # ошибка, если файла не существует
vit01> # ошибка, если файл приватный и pauth неверный

vit01> POST /x/file filename=string
vit01> # содержимое файла, если публичный
vit01> # в ином случае ошибка
vit01> ====

Вроде да. По крайней мере тесты в таверне дают именно такое поведение и именно так я понял изначальный посыл с двумя схемами.

AL> Вроде да. По крайней мере тесты в таверне дают именно такое поведение и именно так я понял изначальный посыл с двумя схемами.

Тогда ещё надо бы будет уточнить в стандарте, что POST-запросы имеют приоритет перед GET-ом.

Либо сегодня, либо завтра поправлю собственную ноду, стандарт и клиенты.

AL> Вероятность того, что authkey будет хотя бы напоминать имя ркального файла болтается где-то в районе нуля. У нас и коллизии в msgid могут запросто возникнуть, но с исчезающе малой вероятностью. Потому я считаю, что простой проверки по поинтлисту достаточно, чтобы определить что это пользователь передал.

Дело здесь не в самих ошибках в коде и коллизиях. Суть в костылях, которые надо нагромождать в исходниках, чтобы заставить это работать. Причём на разных нодах они могут приводить к разному поведению, и это очень неудобно.

vit01>> Вот почесал репу и придумал вариант, который устроит нас обоих. Можно разделить /x/file на 2 схемы: одна для списка, другая для скачивания.

AL> Сделал в таверне такой вариант. Попробовал его и с GET и с POST запросами. Понравилось. Пока из всего, что мы надумали, этот вариант мне нравится более всего.

Насчёт POST прошу уточнить, т.к. это важно. Мы делаем примерно такой вариант?

POST /x/filelist
# публичный список

POST /x/filelist pauth=string
# приватный + публичный список, либо только публичный, если неверно

POST /x/file pauth=string, filename=string2
# содержимое файла, если pauth верный или filename публичный
# ошибка, если файла не существует
# ошибка, если файл приватный и pauth неверный

POST /x/file filename=string
# содержимое файла, если публичный
# в ином случае ошибка