W skrócie
Kliknij teraz dowolny request w Activity, a zobaczysz pełny payload. Kolejne kliknięcie otwiera go z powrotem w Playground, z uzupełnionymi polami i gotowego do ponownego uruchomienia. Wykryliśmy też klasę "proxy", która odsyła Twój własny request jako fałszywy response, i zablokowaliśmy ją, aby nie zanieczyszczała Twoich danych.
Co nowego
Activity → Playground: odtworzenie dowolnego requestu
Każde wywołanie API zwraca header X-Foura-Request-Id. Ten sam identyfikator pojawia się obok requestu w Activity. Kliknij dowolny wiersz, aby zobaczyć pełny obraz: kiedy został uruchomiony, który klucz go wygenerował, request body, response, kody statusu oraz czas trwania. Kliknij "Open in Playground", a request załaduje się do formularza z uzupełnionymi polami.
Dawniej ponowne uruchomienie oznaczało odtwarzanie requestu z pamięci. Teraz Activity przechowuje historię, a Playground działa jak przycisk ponownego uruchomienia.
Kilka kwestii technicznych. Przechowujemy ostatnie 200 payloadów na każdy klucz API przez 24 godziny. Po tym czasie starsze wpisy są zastępowane nowymi. Gdy payload wygaśnie, okno dialogowe poinformuje Cię o tym, zamiast wyświetlać mylące null lub "(empty body)", jak to miało miejsce wcześniej.
Identyfikator requestu też możesz powiązać. Zapisz header response X-Foura-Request-Id obok własnego identyfikatora requestu po stronie klienta, a znalezienie pasującego wiersza w Activity zajmie Ci jedno wklejenie.
Przechwytywanie danych działa poza główną ścieżką krytyczną. Twój request API nigdy na nie nie czeka. A jeśli magazyn przechwyconych danych będzie nieosiągalny, połączenie i tak zostanie zrealizowane, a w oknie dialogowym zobaczysz później komunikat "no body captured".
Walidacja na podstawie response body
Sekcja Validate w Playground zyskała reguły dotyczące zawartości body. Możesz ustawić warunek "zakończ sukcesem tylko, jeśli response zawiera X" lub "zakończ błędem, jeśli zawiera Y", z wieloma alternatywami rozdzielonymi znakiem |. Działa to dla Single i Proxy. Przydatne, gdy kody statusu kłamią o tym, co naprawdę się stało.
Payloady bez body same wyjaśniają swój stan
Nieudane requesty nie mają response body do wyświetlenia. Stare okno dialogowe renderowało to jako null lub "(empty body)", co łatwo było błędnie zinterpretować jako rzeczywisty pusty response. Teraz okno dialogowe rozróżnia trzy przypadki: request zakończył się błędem (z konkretnym komunikatem o błędzie), payload nie został przechwycony lub serwer rzeczywiście zwrócił zero bajtów.
Mała rzecz, ale eliminuje powtarzające się wątpliwości typu "zaraz, czy to był response, czy błąd w interfejsie?".
Przycisk Reset w Playground
Przywraca domyślne wartości formularza aktywnego endpointu jednym kliknięciem. Domyślnie opcje unblocker i tryJsonData pozostają włączone, ponieważ to z nich korzysta się w 90% przypadków.
Pod maską
Wykrywanie honeypot proxy
Niektóre proxy działające w sieci wcale nie przekazują ruchu dalej. Odsyłają Twój własny request jako zrzut zmiennych serwerowych w formacie tekstowym (metoda HTTP, headery, host docelowy), aby ich operator mógł przejąć wszystko, co się w nim znajdowało. Widzieliśmy przypadki, gdy to samo proxy przekazało jeden request, kolejny odesłało jako echo, a przy jeszcze następnym zwróciło błąd 502, a wszystko to w ramach jednej sesji.
Walidator body wykrywa teraz sygnaturę takiego zrzutu, zanim response opuści naszą infrastrukturę brzegową. Single zwraca czytelny błąd. Proxy Finder ponawia próbę z innym proxy. Browser dziedziczy to samo zabezpieczenie ze wspólnej warstwy HTTP. Dzięki temu zobaczysz mniej śmieciowych wierszy w Activity, a Twoje scrapery nie pobiorą czegoś, co wygląda jak dane, a w rzeczywistości jest tylko próbą sondowania.
Na razie nie zmieniamy reputacji tych adresów. Proxy pozostaje tymczasowo w puli. Po prostu odmawiamy przekazania Ci jego kłamstwa.
Podsumowując: jeśli request trafi do Activity oznaczony jako twardy błąd, a wcześniej wyglądał na pozorny "sukces", oznacza to, że zadziałało nasze zabezpieczenie. Lepiej otrzymać wyraźny błąd niż skażony rekord.