Highlights
Два изменения на этой неделе влияют на то, что возвращается в ответе на ваши запросы. Тела response больше не приходят в виде кракозябр на сайтах с кодировкой, отличной от UTF-8, а принятые через validate ответы с кодами, отличными от 200, наконец-то считаются успешными вместо ошибок. Мы также устранили пару уязвимостей в клиентском API.
What's New
Non-UTF-8 pages return readable text on Single
Если вы вызываете Single для болгарских форумов, китайских интернет-магазинов, японских новостей или любых ресурсов, отдающих windows-1251, GBK, Big5 или Shift_JIS, тело response раньше возвращалось в виде битых байтов. Внутренний HTTP-слой использовал жестко зашитый декодер UTF-8, поэтому кириллическая страница приходила в виде промоции, и восстановить оригинал на вашей стороне было невозможно.
Это исправлено на уровне обработки request. Single теперь определяет исходную кодировку (сначала через header Content-Type, затем через <meta charset>, а после через <meta http-equiv>) и перекодирует ее в UTF-8 до того, как тело попадет в ваш JSON-конверт. А страницы в UTF-8 или ASCII проходят без изменений. Бинарный контент, такой как изображения или PDF, никогда не декодируется. Если вам нужны сырые байты, параметр returnBuffer: true по-прежнему возвращает исходный буфер.
Включено по умолчанию. Никаких флагов переключать не нужно. Страницы, которые работали раньше, продолжают работать; страницы, возвращавшие мусор, теперь отдают читаемый текст. Пользователям браузера об этом тоже можно не думать: Chromium декодирует кодировки нативно.
validate rules now drive success classification
Когда вы настраивали validate для request (например, validate.status.accept = [200, 403]), движок request уже учитывал ваше правило и обрабатывал response без ошибок. Но наш классификатор результатов на более высоком уровне игнорировал ваше правило и отправлял все, что не являлось чистым 200, в категорию application_fail. Два последствия: ваш принятый код 403 отображался как ошибка в Dashboard, и, поскольку тарифицируются только успешные запросы, за эти доставленные ответы плата также не взималась.
Теперь классификатор учитывает то, что указано в validate. Запросы с validate считаются успешными каждый раз, когда движок обработал их без ошибок, независимо от статуса. Запросы без validate ведут себя так же, как и раньше (успешными считаются только ответы с кодом 200), поэтому старая логика не изменилась.
Исправление применяется только для новых данных: исторические строки сохраняют свой записанный результат, а новые запросы классифицируются корректно. Так что если вы видели статус App Fail для ответов, которые заведомо считали валидными, причина была именно в этом.
Security hardening on the customer API
Мы развернули Wave 0 в рамках аудита безопасности клиентского API:
- CORS теперь ограничен доменом
https://foura.ai. Предыдущая настройка возвращала любой origin при отправке учетных данных, что является классической уязвимостью для CSRF. Это не влияет на запросы из того же источника (same-origin) в браузере и на вызовы API на стороне вашего сервера. - Маршрут метрик (metrics route), отвечающий за таймлайн вашей активности (Activity), ранее принимал фильтр
outcomeв свободной форме, который попадал напрямую в запрос. Теперь он ограничен белым списком известных значений outcome. Эту уязвимость нельзя было использовать из обычного аккаунта, но ее стоило закрыть.
Ни одно из изменений не нарушает контракт API. Вы не заметите их при обычном использовании. Но обнаружение проблемы и ее устранение до того, как кто-то ее заметит, все равно заслуживает упоминания.
Activity labels match the Overview
Небольшое улучшение. Таблица Activity в вашем Dashboard ранее отображала сырые строки результатов вроде Application_fail, в то время как плашки, круговая диаграмма и таймлайн в Overview показывали понятные метки (App Fail) и выделяли каждый результат цветом. Те же данные, два разных представления. Теперь они синхронизированы и используют одну и ту же карту меток и цветов, поэтому статус строки выглядит одинаково, где бы вы его ни проверяли.
Numbers
На этой неделе нет новых данных по latency или success-rate. Большая часть проделанной работы связана с корректностью и безопасностью, где правильная метрика состоит в том, чтобы перестать ошибаться, а не работать быстрее. В дайджесте на следующей неделе должны появиться данные по пропускной способности (throughput) для нескольких запущенных процессов.