Комментарии 19
Если про Retry-After я узнал далеко не сразу, то Authorization встречается довольно часто, и странно слышать, что про него может не знать миддл-бэкенд разраб. Даже если вы сами не пишете апи, то тот же Bearer-токен встречается относительно часто в сторонних апишках, который как раз в этом заголовке и передается
UPD: да Basic тоже встречается не то чтобы редко
И тем не менее, согласен с автором статьи, что многие API (в том числе и в банках), используют какие-то свои заголовки для передачи авторизационных параметров.
Да, в целом, не сказал бы что это прям ужасно, но все-таки хочется видеть какое-то единообразие.
Плюс в некоторых языках (библиотеках) есть готовые хелперы для работы с заголовком Authorization (и не только), что упрощает код и минимизирует шанс ошибиться как в формате, так и в названии самого заголовка. Когда же работаем с кастомным заголовком, то ничего подобного, естественно, нет.
Ужасно это может быть только, если вы сохраняете трафик каким-нибудь HttpWatch для коллеги, и он увидит ваш пароль вместо звёздочек. Просто потому, что ваш инструмент не знал, какой заголовок оказался секретным.
Статья написана исключительно с целью прорекламировать свою контору. Ценность если и несёт, то для совсем зелёного джуна. Засилье корпоративных аккаунтов на Хабре в последние годы делает совершенно невозможным его чтение, всем нужно рекламировать и продавать какую-нибудь дрянь.
А ещё, видимо, мало кто знает что заголовки могут дублироваться по имени. Часто вижу как заголовки собирают в dict..
И иметь два заголовка Authorization - это нормально. Например, Basic может на nginx отсекать ботов, а в приложении уже логика проверяет пользователя по базе.
IMO, веб-разработчики не знают про заголовки HTTP потому, что в принципе не понимают, что такое HTTP. Если изучить не отправление токенов в заголовках для решения тестовых заданий, а саму суть HTTP-протокола, зачем он нужен и с чем его едят, то большинство вопросов исчезнут (= эти вопросы будут выглядеть как гугл необходимых хедеров в твой запрос).
Т.е. вся статья рассказывает о 2х заголовках и помещаеться на лист А4?
Мощно однако..
Было бы неплохо услышать про полезность Cache-Control: public в современном вебе, где всё за tls...
Только вот хедеры не работают с web-socket и приходится этот токен добавлять в параметры
О чем статья, если не секрет? Откровенно ожидал узнать для себя что то новое. Не вышло.
Заголовки авторизации используются сейчас очень часто. Кеш - аналогично гуглится первой ссылкой на какой нибудь so.
Единственное что хорошо - accept. С другой стороны - а как часто он на самом деле потребовался? При работе с некоторым апи мы точно знаем что нам для него надо и можем легко подстроиться под него заранее. Любой адекватный апи давно работает с джсоном и только с ним. Да даже всякие ардруины, которым заголовок может реально понадобится, например для какого нибудь XML(предположим) - умеют в json и с огромным успехом чудес перезагрузок операторов умеют в большое удобство при работе с json.
Про Retry-After давно не слышал. Хотя в университете про HTTP и его заголовки очень даже рассказывали (и даже просили написать HTTP-сервер).
А вот про Authorization не со всем соглашусь - бывает, что нужно всю информацию, требуемую для запроса, положить в URL. Например - токены доступа по ссылке (когда нужно что-то расшарить людям, которым известна ссылка, по типу документов в Google Drive). Потому в каждом случае надо отдельно разбираться.
А ещё, раз уж про авторизацию заговорили, можно вспомнить Basic HTTP Auth, для которого в частности имя пользователя и пароль можно задавать прямо в URL: <scheme>://<user>:<password>@<host>/<path>. И это даже вполне себе работает.
(там, где я учился, определённо, так и было)
Учился, ага. Автор оригинала — женщина.
Пара HTTP-заголовков, о которых, похоже, не знают разработчики