Отец веба покарал Гугл, Фейсбук и французов

Ты передаёшь настройки сайта в заголовках? Это ничем не отличается от FTP команд(кроме лишних символов [-:] и передачи на каждый файлик). Или ты передаёшь «ID», ко которому сервер находит у себя твои настройки? Для этого в FTP с 71 года есть специальный хидер CWD - опять короче, только 1 раз на сессию и безопасно.

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

Алсо что делать с нестандартными хидерами?

Шареный стейт это кукисы и JWT токены.

Где тут тормоза и простои?

В заднице же(backend по ихнему)! Тамошние сервера должны синхронизировать изменяющееся состояние, что натыкает их на «CAP theorem», с неизбежными жертвами.

вместо команды с атрибутами нужно передавать серию команд, из которых сервер должен сделать команду с атрибутами, но сам?

Разве это не то, что твой сервер делает с «шаред стейтом»? Делать это от «команды с параметрами» или от «значения аттрибутов в запросе» - сугубо косметическая разница, непонятно зачем мы её столько обсуждаем.

При этом выполнение нескольких команд требует нескольких TCP соединений

Команд передачи данных - да, и это ускоряет упаралеливанием, клинеты довольны. «управляющих»(типа там согласования параметров или логина) - нет смысла, в одном потоке - меньше дублирования. Впорчем можно, и многие это делали для ускорения канонически синхронного FTP, и ничего не отсохло.

В заднице же(backend по ихнему)! Тамошние сервера должны синхронизировать изменяющееся состояние, что натыкает их на «CAP theorem», с неизбежными жертвами.

JWT и куки в бекенде? АХАХАХАХАХАХАХАХАХАХА. Тот редкий момент, когда я жалею, что капса второго уровня не существует.

Команд передачи данных - да, и это ускоряет упаралеливанием, клинеты довольны.

Правда нужно открыть вторую TCP сессию, что охренительно увеличивает латентность, но кого такие мелочи волнуют, правда?

АХАХАХАХАХАХАХАХАХАХА

Да, это объясняет твою позицию.

открыть вторую TCP сессию, что охренительно увеличивает латентность

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

Да, это объясняет твою позицию.

Ты дебик что ли? :)) JWT специально придумали для stateless authenticaion, лалка.

JWT специально придумали

Что, никак не отменяет всего предыдущего. По очевидным причинам.

Ты дебик

Если ты так настаиваешь, будем считать это достаточным обоснованием.

Что, никак не отменяет всего предыдущего. По очевидным причинам.

Чего именно? Или ты думаешь, что по какой-то странной причине тебе не нужно будет на построенном через FTP CDN'е файлы синхронизировать, потому что он такой божественный и будет через libastral работать? :)))

Чего именно

Ничего. То, что клиент прислал тебе подписанный блоб (или что там ещё твой jwt делает) никак не отменяет простого факта: либо этот блоб содержит все данные пользовательской сессии, и это никак не лучше FTP, т.к. присылаются и проверяются на каждый запрос, либо он прислал только «номер» сессии, и твои сервера вынуждены синхронизировать инфу о сессиях между собой, или держать в общей базе, и то и другое == проблемы.

потому что он такой божественный

Это ты придумал. Я, всего лишь, утверждаю, что то, как мы нынче используем веб, требует обставлять HTTP нецензурным количеством костылей, значительная часть которых не понадобилась бы, если бы мы ранее предпочли транспортировать его старым добрым FTP. куки, тлс. /2, жвты и прочие токены,[...] - есть не решение универсальных вселенских проблем(*), а решение проблем конкретно нашего способа применения конкретного HTTP. Нет HTTP - нет проблем, не нужны эти костыли. Иное применение HTTP - нет проблем, не нужны эти костыли.

Да, у ftp были бы свои проблемы и, вероятно, свои костыли. И наверняка были бы решения не-протоколоспецифичных проблем(тот же шареный стейт, например). Но приводить костыли http-а в качестве обоснования его превосходства - плохая, негодная логика.

Ничего. То, что клиент прислал тебе подписанный блоб (или что там ещё твой jwt делает) никак не отменяет просого факта: либо этот блоб содержит все данные пользовательской сессии, и это никак не лучше FTP, т.к. присылаются и проверяются на каждый запрос, либо он прислал только «номер» сессии, и твои сервера вынуждены синхронизировать инфу о сессиях между собой, или держать в общей базе, и то и другое == проблемы.

Лал. Для проверки валидности JWT нужно проверить время подписи и саму подпись. Для проверки FTP кредов нужно проверять логин/пароль. Так что у FTP стейт будет шареный через бекенд, а у HTTP нет :)))

Для проверки валидности JWT нужно проверить время подписи и саму подпись. Для проверки FTP кредов нужно проверять логин/пароль

Да. Второе дешевлее(cpu меньше).

у FTP стейт будет шареный

Пароль пользователи меняют раз в никогда. Т.ч. это «неизменяемый шареный стейт», у него сильно меньше проблем. А токены нужно перегенерировать минмиум раз в сессию. Проблемы начинаются, когда пользователь ползает по сайту и каждый клик изменяет состояние сессии. Или редиректится куда-то наружу (например для оплаты), и через надцать минут должет вернуться и продолжить с того же места. Почему это не очевидно?

Да. Второе дешевлее(cpu меньше).

LOL. Только ты забыл, что пароли закриптованы, и их тоже нужно проверять по хешу. Это если у тебя не LDAP (ты ведь не хочешь на каждой ноде хранить полную базу логинов паролей, верно?). Потому что если у тебя LDAP, то к нему ты цепляешься по TLS... ну ты понел, да? :)))

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

Бгг. А новые пользователи появляются часто. У тебя, конечно, нет, но вообще да.

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

Для этого есть кукисы. JWT нужен для тех вещей, которые критичны (пермиссии и валидация пользователя), и которые ты не можешь доверить клиенту хранить самому (потому что он может их подделать).

Или редиректится куда-то наружу (например для оплаты), и через надцать минут должет вернуться и продолжить с того же места. Почему это не очевидно?

Потому что ты чушь несешь, лол.

их тоже нужно проверять по хешу

Это дешевлее асиметричной криптографии по тому же хешу(как я понял жвт делает).

если у тебя LDAP, то к нему ты цепляешься по TLS

Не обязательно - в безопасную проверку паролей без шифрования канала умеют все, кроме большинства вебогенов.

Впрочем, выигрыш тут почти незаметен, не стоит обсуждения.

доверить клиенту хранить самому

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

Короче, давай закончим на прошлом обосновании.

Это дешевлее асиметричной криптографии по тому же хешу(как я понял жвт делает).

Дешевле, но не сильно.

Не обязательно - в безопасную проверку паролей без шифрования канала умеют все, кроме большинства вебогенов.

Лол. То есть возможный MITM тебя не смущает?

возможный MITM тебя не смущает

Между 2мя моими серверами в одном шкафу/дц не смущает. В церберовом реалме не смущает. Между моим бровзером и лором не смущает (например, это сообщение прошло минимум 2х, очень вероятно 3х, не удивлюсь, если 4..5).

Когда я полезу переводить со счёта на ветер - начнёт немножко смущать; но, как ты понимаешь, это 1. ничтожно малая часть трафика, 2. я всё равно не могу гарантировать отсутствие MITM-ов. Т.к. ни разу не чистил список CA, и ни разу не проверял, как там у банка всё усекурено. Осознавая, что моя успокоенность видом зелёного замочка обоснована только незначительным балансом моих счетов, итог — почти никогда не смущает.

Между 2мя моими серверами в одном шкафу/дц не смущает.

CDN подразумевает, что их много, лол.

Когда я полезу переводить со счёта на ветер - начнёт немножко смущать; но, как ты понимаешь, это 1. ничтожно малая часть трафика, 2. я всё равно не могу гарантировать отсутствие MITM-ов. Т.к. ни разу не чистил список CA, и ни разу не проверял, как там у банка всё усекурено. Осознавая, что моя успокоенность видом зелёного замочка обоснована только незначительным балансом моих счетов, итог — почти никогда не смущает.

Я только не понял, причем тут клиентская часть, когда мы бекенд обсуждаем, лол.

CDN подразумевает, что их много

А лдапов, конечно только один. Пололься ещё.

мы бекенд обсуждаем

Тогда совсем не смущает.

А лдапов, конечно только один. Пололься ещё.

Не ты ли про cap-теорему задвигал? Алсо не все датацентры твои. По большей части не твои.

Тогда совсем не смущает.

Ну на этом можно заканчивать, наверное.