Акценти
Две промени тази седмица засягат това, което се връща от вашите заявки. Телата на отговорите (response bodies) спират да пристигат като неразбираеми символи от сайтове без UTF-8, а отговорите, различни от 200, които са приети от validate, вече се отчитат като успех вместо като неуспех. Също така затворихме няколко дупки в сигурността в потребителския API.
Какво ново
Страниците без UTF-8 връщат четим текст в Single
Ако извикате Single за български форуми, китайска електронна търговия, японски новини или каквото и да било, което използва windows-1251, GBK, Big5 или Shift_JIS, тялото на отговора преди се връщаше като счупени байтове. Основният HTTP слой имаше твърдо кодиран UTF-8 декодер, така че кирилска страница пристигаше като промоции и нямаше начин да възстановите оригинала от ваша страна.
Това е поправено на ниво заявка. Single вече открива изходния набор от символи (чрез заглавката Content-Type, след това <meta charset>, след това <meta http-equiv>) и транскодира в UTF-8 преди тялото да достигне до вашия JSON обект. А UTF-8 или ASCII страниците преминават непокътнати. Двоично съдържание като изображения или PDF файлове никога не се декодира. Ако искате суровите байтове, returnBuffer: true все още връща оригиналния буфер.
Включено по подразбиране. Няма флаг за превключване. Страниците, които са работили преди, продължават да работят. Страниците, които са връщали боклук, сега връщат четим текст. Потребителите на браузъра също не трябва да мислят за това. Chromium декодира наборите от символи нативно.
Правилата validate вече определят класификацията за успех
Когато зададете validate за дадена заявка (например validate.status.accept = [200, 403]), машината за заявки вече е уважила вашето правило и е разрешила отговора без грешка. Но нашият класификатор на резултатите преди това игнорираше вашето правило и категоризираше всичко, което не е точно 200, като application_fail. Това имаше две последствия: вашият приет 403 се показваше като неуспех в Dashboard и тъй като се таксува само успех, тези доставени отговори също оставаха нетаксувани.
Класификаторът вече спазва това, което validate е декларирал. Заявките с validate се отчитат като успех, когато машината ги разреши без грешка, независимо от статуса. Заявките без validate се държат по същия начин както преди (успех само при 200), така че старият път (legacy path) остава непокътнат.
Корекция само занапред: историческите редове запазват съхранения си резултат, новите заявки се класифицират правилно. Така че ако сте виждали App Fail в отговори, за които знаете, че са валидни, това е причината.
Повишаване на сигурността в потребителския API
Внедрихме Wave 0 от преглед на сигурността в потребителския API:
- CORS вече е ограничен до
https://foura.ai. Предишната настройка отразяваше всеки произход (origin) при изпращане на идентификационни данни, което е стандартната CSRF конфигурация. Извикванията от браузъра със същия произход (same-origin) и вашите API извиквания от страна на сървъра не са засегнати. - Маршрутът за метрики зад вашата времева линия Activity преди приемаше филтър
outcomeв свободна форма, който влизаше директно в заявката. Сега той е ограничен до известни стойности на резултатите. Не може да се експлоатира от нормален акаунт, но си струваше да се затвори.
Никоя от двете промени не променя API договора. Няма да ги забележите при нормална употреба. Но откриването на проблем и затварянето му, преди някой да забележи, все пак заслужава да бъде споменато.
Етикетите в Activity съвпадат с Overview
Малка промяна. Таблицата Activity във вашия Dashboard преди рендираше сурови низове за резултати като Application_fail, докато елементите в Overview (чипове, графика тип поничка и времева линия) показваха по-приятелски етикети (App Fail) и оцветяваха всеки резултат. Едни и същи данни, две представяния. Сега те са синхронизирани. И двете четат от една и съща карта за етикети и цветове, така че статусът на даден ред изглежда по един и същ начин, където и да го проверите.
Числа
Тази седмица не носи нови числа за латентност (latency) или процент на успеваемост (success-rate). Повечето от това е работа по коректността и сигурността, където правилната метрика е "спри да грешиш" вместо "движи се по-бързо". Обобщението следващата седмица трябва да съдържа данни за пропускателната способност (throughput) от няколко неща, които са в процес на изпълнение.