Highlights
Zwei Änderungen in dieser Woche betreffen die Rückgabewerte deiner Requests. Response-Bodys kommen auf Nicht-UTF-8-Seiten nicht mehr als Zeichensalat an, und über validate akzeptierte Non-200-Responses zählen endlich als Erfolg statt als Fehler. Zudem haben wir einige Sicherheitslücken in der Kunden-API geschlossen.
Neuerungen
Nicht-UTF-8-Seiten geben bei Single lesbaren Text zurück
Wenn du Single auf bulgarischen Foren, chinesischen E-Commerce-Seiten, japanischen Nachrichten oder anderen Seiten aufrufst, die windows-1251, GBK, Big5 oder Shift_JIS ausliefern, kam der Response-Body bisher als fehlerhafte Bytes zurück. Die zugrundeliegende HTTP-Ebene nutzte einen fest codierten UTF-8-Decoder, sodass eine kyrillische Seite als промоции ankam und es für dich keine Möglichkeit gab, das Original wiederherzustellen.
Das ist auf der Request-Ebene behoben. Single erkennt jetzt den Quell-Zeichensatz (über den Content-Type-Header, dann <meta charset>, dann <meta http-equiv>) und transkodiert ihn nach UTF-8, bevor der Body deinen JSON-Envelope erreicht. Und UTF-8- oder ASCII-Seiten werden unverändert durchgereicht. Binäre Inhalte wie Bilder oder PDFs werden niemals decodiert. Wenn du die Rohdaten-Bytes möchtest, liefert returnBuffer: true weiterhin den ursprünglichen Buffer zurück.
Standardmäßig aktiv. Kein Flag, das du umlegen musst. Seiten, die vorher funktionierten, funktionieren weiterhin, Seiten, die Müll zurückgaben, liefern jetzt lesbaren Text. Browser-Nutzer müssen sich darüber ebenfalls keine Gedanken machen, Chromium decodiert Zeichensätze nativ.
validate-Regeln steuern jetzt die Erfolgsklassifizierung
Wenn du validate für einen Request festlegst (zum Beispiel validate.status.accept = [200, 403]), hat die Request-Engine deine Regel bereits berücksichtigt und die Response ohne Fehler aufgelöst. Aber unser Upstream-Outcome-Classifier hat deine Regel ignoriert und alles, was keine exakte 200 war, als application_fail eingestuft. Zwei Folgen: Deine akzeptierte 403 tauchte im Dashboard als Fehler auf, und da nur erfolgreiche Requests abrechenbar sind, wurden diese zugestellten Responses auch nicht berechnet.
Der Classifier berücksichtigt nun, was validate deklariert hat. Requests mit validate zählen immer dann als Erfolg, wenn die Engine sie fehlerfrei aufgelöst hat, unabhängig vom Status. Requests ohne validate verhalten sich wie bisher (Erfolg nur bei 200), sodass der Legacy-Pfad unberührt bleibt.
Der Fix gilt nur für die Zukunft: Historische Zeilen behalten ihr gespeichertes Ergebnis, neue Requests werden korrekt klassifiziert. Wenn du also App Fail bei Responses gesehen hast, von denen du wusstest, dass sie valide waren, war dies der Grund.
Sicherheitshärtung der Kunden-API
Wir haben Wave 0 einer Sicherheitsüberprüfung für die Kunden-API veröffentlicht:
- CORS ist jetzt auf
https://foura.aibeschränkt. Die vorherige Einstellung spiegelte jeden Origin beim Senden von Credentials wider, was dem Standard-CSRF-Setup entspricht. Same-Origin-Browseraufrufe und deine serverseitigen API-Aufrufe sind davon nicht betroffen. - Die Metrics-Route hinter deiner Activity-Timeline akzeptierte bisher einen frei definierbaren
outcome-Filter, der direkt in die Query einfloss. Sie ist jetzt auf bekannte Outcome-Werte beschränkt (Allowlist). Von einem normalen Account aus nicht ausnutzbar, aber es war wichtig, diese Lücke zu schließen.
Keine der Änderungen ändert einen API-Contract. Im normalen Betrieb wirst du davon nichts bemerken. Aber ein Problem zu finden und zu beheben, bevor es jemand bemerkt, ist es dennoch wert, erwähnt zu werden.
Activity-Labels entsprechen der Overview
Eine Kleinigkeit. Die Activity-Tabelle in deinem Dashboard stellte bisher rohe Outcome-Strings wie Application_fail dar, während die Overview-Chips, das Donut-Diagramm und die Timeline benutzerfreundliche Labels (App Fail) anzeigten und jedes Ergebnis farblich codierten. Dieselben Daten, zwei Darstellungen. Sie sind jetzt synchronisiert und greifen auf dieselbe Label- und Farbzuordnung zu, sodass der Status einer Zeile überall gleich aussieht, wo du ihn prüfst.
Zahlen
Diese Woche bringt keine neuen Zahlen zu Latenz oder Erfolgsquote. Der Großteil dieser Arbeit betraf Korrektheit und Sicherheit, wobei die richtige Metrik eher "Fehler vermeiden" als "schneller werden" lautet. Der Digest der nächsten Woche sollte Durchsatzdaten zu einigen derzeit in Arbeit befindlichen Dingen enthalten.