Комментарии 12
Время установки https соединения «на холодную» порядка 200ms, т.к. процесс обмена ключами не быстрый… Это довольно долго, по сравнению с http. Для того, чтобы уменьшить это время в ssl и tls был добавлен механизм сессионных ключей. Сайт.эффект в том, что теперь на сервере можно связвывать серию запросов гарантируя, что они пришли от одного клиента. h2 это способ решить ту же самую задачу, другим способом — завернуть всю сессию в одно соединение. На практике оба способа можно использовать вместе. Делает-ли это интернет более безопасным? Смотря для кого.
GET — идемпотентный метод, означающий, что независимо от того, сколько запросов вы отправите, вы не будете изменять состояние веб-сервера
Вы серьёзно?
То, что вы описали про плагин это не атака и не недостаток GET'а, а скорее две столкнувшиеся беды — криворукая реализация и кривой плагин. То есть эта та ситуация где ты сам себе злой буратино и это скорее подтерждает мои слова, что фраза в этой статье некорректна и GET чего только не может. Про REST тут не имеет смысла ничего писать, потому что он не имеет отношения к статье и о его недостатках можно говорить не меньше чем о его достоинствах. Я ещё раз уточню раз вам не понятно, о том, что мне не понравилось в посте. Там написано описание метода протокола, а не рекомендации по его использованию и указано, что GET всегда идемпотентен, что не правда и это даже вы сами подтвердили своим опытом со страницей с delete-ссылками. И это не недостаток данного перевода, а недостаток статьи оригинала. И всё бы ничего, если бы не было указано в заголовке статьи слов «Web Security». А security как раз заканчивается там, где под её соусом подают недостоверную информацию и у людей появляется иллюзия её наличия. И если начинающий разработчик-домохазяйка начнёт юзать GET'ы, думая что они не могут менять состояния сервиса, прочитав информацию в данной статье-руководстве, то последствия могут быть самыми разными.
RFC дает рекомендации, чтобы не создавать и не наступать на грабли. Но это ни сколько не мешает их создавать или наступать на ровном месте. Незграмотность и самоуверенность это страшная сила.
Вот в случае с Телеграм бот-апи это «неграмотность и самоуверенность»? Да и при чем тут грабли? Какие грабли? Аргументация какая-либо начнётся? Я вроде ещё в предыдущем комментарии старался вам объяснить, что выбор метода к безопасности не имеет отношения даже если один из них идемпотентный, а вы все про тоже, да потому же… И персональный мир с единорогами и ромашками заканчивается на этапе взаимодействия со сторонними сервисами в которых может встретиться всё что угодно. И кроме принятия на веру, что что-то плохо важно понимать почему и в каких ситуациях. Считаю диалог исчерпанным из-за отсутствия конструктивной критики.
Веб работает на соглашениях. Это вещи, которые подразумеваются по умолчанию. Идемпотентность дает такие плюшки как возможность выполнять запросы многократно без последствий и отдавать результаты из кеша. Это свойство используют браузеры, прокси серверы, поисковые системы и т.п. Оно позволяет обмениваться ссылками, так что каждый получит то же, что и вы.
Привычка смешивать GET и POST была популяризирована в php, что снижало порог входа. Позже подход многократно критиковался.
У разработчиков API, которое вы приводите в пример, вероятно были какие то свои мотивы для отклонения от стандартов, без объяснения которых я бы не стал тут показывать как эталон.
Web Security: введение в HTTP