Highlights
Две промени от тази седмица засягат това, което получавате обратно от вашите requests. Телата на responses вече не пристигат като mojibake при сайтове, които не използват UTF-8, а приетите чрез validate non-200 responses най-накрая се отчитат като успех вместо като грешка. Също така затворихме няколко пропуски в сигурността на клиентското 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 сега открива кодирането на източника (чрез Content-Type header, след това <meta charset>, а след това <meta http-equiv>) и го прекодира в UTF-8, преди тялото да достигне до вашия JSON envelope. А страниците в UTF-8 или ASCII преминават непроменени. Двоично съдържание като изображения или PDF файлове никога не се декодира. Ако искате суровите байтове, returnBuffer: true все още връща оригиналния буфер.
Включено по подразбиране. Няма флагове за превключване. Страниците, които са работили преди, все още работят, а страниците, които връщаха боклуци, сега връщат четим текст. Потребителите на браузъри също не трябва да мислят за това, Chromium декодира кодиранията на символите нативно.
validate rules now drive success classification
Когато зададете validate за даден request (например validate.status.accept = [200, 403]), енджинът за requests вече зачиташе вашето правило и обработваше response без грешка. Но нашият outcome classifier нагоре по веригата игнорираше вашето правило и разпределяше всичко, което не беше буквално 200, като application_fail. Две последствия: вашият приет 403 се показваше като грешка в Dashboard, и тъй като само успешните заявки се таксуват, тези доставени responses също оставаха нетаксувани.
Класификаторът вече зачита декларираното от validate. Requests с validate се отчитат като успешни винаги, когато енджинът ги е обработил без грешка, независимо от статуса. Requests без validate се държат по същия начин, както преди (успех само при 200), така че старото поведение остава непроменено.
Корекция само занапред: историческите редове запазват записания си outcome, новите requests се класифицират правилно. Така че, ако сте виждали App Fail за responses, за които сте знаели, че са валидни, това е причината.
Security hardening on the customer API
Внедрихме Wave 0 от прегледа на сигурността в клиентското API:
- CORS вече е ограничен до
https://foura.ai. - Предишната настройка отразяваше всеки origin при изпращане на credentials, което е стандартната CSRF конфигурация. Повикванията от същия origin в браузъра и вашите API повиквания от страна на сървъра не са засегнати.
- Пътят за метрики (metrics route) зад вашата Activity хронология преди приемаше свободен филтър
outcome, който отиваше директно в заявката. Сега той е ограничен с allowlist до известни стойности за outcome. Не може да се експлоатира от нормален акаунт, но си струваше да бъде затворен.
Нито една от промените не променя съществуващите API договори. Няма да ги забележите при нормална употреба. Но откриването на проблем и отстраняването му, преди някой да забележи, все пак заслужава да бъде споменато.
Activity labels match the Overview
Нещо малко. Таблицата Activity във вашия Dashboard показваше сурови низове за резултат като Application_fail, докато елементите, поничката (donut) и хронологията в Overview показваха по-разбираеми етикети (App Fail) и цветно кодираха всеки outcome. Едни и същи данни, две различни представяния. Сега те са синхронизирани и четат от една и съща карта с етикети и цветове, така че статусът на даден ред изглежда еднакво, където и да го проверите.
Numbers
Тази седмица няма нови данни за latency или success-rate. По-голямата част от това е работа по коректността и сигурността, където правилната метрика е „да спрем да грешим“, а не „да работим по-бързо“. Дайджестът за следващата седмица трябва да съдържа данни за пропускателната способност (throughput) от няколко неща, които са в процес на изпълнение.