Redirect-Ketten brechen Scraper ab. Binäre Responses werden beschädigt, wenn man sie als Text decodiert. Zwei Probleme, die ständig auftreten, sobald du über die Phase "Seite abrufen, HTML parsen" hinaus bist.
Wir haben zwei neue Request-Optionen veröffentlicht, um beides zu lösen: followRedirects und returnBuffer. Sie sind ab sofort in der API verfügbar.
So funktioniert es
Redirect-Kontrolle mit followRedirects
Die meisten Scraping-APIs behandeln Redirects als Boolean: folgen oder nicht. Das funktioniert, bis du auf eine Weiterleitungsschleife triffst oder die zwischenzeitliche 302-Response selbst brauchst, um einen Tracking-Parameter zu extrahieren.
FourAs followRedirects akzeptiert einen Integer zwischen 0 und 20. Lässt du ihn weg (oder setzt 0), erhältst du die rohe Redirect-Response samt Headern zurück. Setzt du ihn auf 5, folgt der Request bis zu fünf Hops, bevor er das endgültige Ergebnis zurückgibt.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
Das folgt bis zu drei Weiterleitungen. Löst sich die Kette in zwei Schritten auf, erhältst du die finale Seite. Ist sie länger als drei, erhältst du das Ergebnis des dritten Hops.
Der Unterschied ist wichtiger, als man denkt. E-Commerce-Websites leiten über Tracking-URLs weiter, bevor sie auf der Produktseite landen. Diesen möchtest du folgen. Doch Affiliate-Netzwerke und URL-Shortener erzeugen manchmal Ketten mit sechs, sieben oder acht Hops. Manche Redirect-Loops enden nie. Die Begrenzung auf eine feste Anzahl sorgt dafür, dass du Daten erfasst, ohne in einer Endlosschleife zu landen, die dein Request-Timeout aufbraucht.
Zuvor bestand der Workaround darin, einen Request ohne Weiterleitungen zu senden, den Location Header manuell zu parsen und einen weiteren Request abzusetzen. Das bedeutet mindestens zwei API-Aufrufe, doppelte Latenz und zusätzlichen Code, den du warten musst. Jetzt reicht ein einziger Aufruf mit einer Zahl.
Rohe binäre Responses mit returnBuffer
Wenn du Bilder, PDFs oder Protobuf-Payloads abrufst, zerstört die Textdecodierung die Daten. Die HTTP-Bibliothek nimmt an, dass die Response Text ist, wendet eine Charset-Erkennung an und beschädigt jedes nicht passende Byte unbemerkt. Protobuf wird unlesbar. Image-Header brechen. Am Ende hast du beschädigte Dateien ohne eine offensichtliche Fehlermeldung, die den Grund erklärt.
returnBuffer weist die API an, die Textdecodierung vollständig zu überspringen.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
Der Response-Body wird als Raw Bytes zurückgegeben (Base64-codiert in JSON-Responses). Dekodiere ihn auf deiner Seite und du hast genau das, was der Server gesendet hat. Keine Charset-Annahmen, keine Encoding-Konvertierung, keine unbemerkte Datenbeschädigung.
Das war eines der häufigeren Support-Tickets bei uns: Nutzer sammelten Produktbilder oder PDF-Kataloge und erhielten Dateien, die sich nicht öffnen ließen. Der Fix war immer derselbe, aber jetzt gibt es dafür ein Flag statt eines Workarounds.
Auswirkungen
Beide Features reduzieren die Anzahl der API-Calls pro Job. followRedirects eliminiert manuelle Redirect-Chasing-Schleifen. returnBuffer eliminiert den Zyklus aus "Abrufen, Beschädigung feststellen, mit anderen Einstellungen erneut abrufen".
Bei Zielen mit vielen Redirects (Affiliate-Links, URL-Shortener, E-Commerce-Tracking-Ketten) sahen wir in frühen Tests einen Rückgang der Request-Zahlen um 40-60%, sobald Nutzer vom manuellen Redirect-Handling auf followRedirects umstiegen. Und bei binären Datenerfassungen (Produktbilder, Dokument-Downloads) macht returnBuffer aus einem mehrstufigen Workaround eine einzelne Option (erste Ergebnisse).
Das sind keine auffälligen Features. Es sind die Dinge, an die du erst denkst, wenn dein Scraper um 3 Uhr morgens abbricht, weil eine Website ihrem Checkout-Flow einen zusätzlichen Redirect-Hop hinzugefügt hat.
Für Power-User
Kombiniere followRedirects mit Response-Validierung für eine präzise Kontrolle über Redirect-Ketten. Folge Redirects, aber lass den Request fehlschlagen, wenn das finale Ziel blockiert wird:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "X-API-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product/12345",
"followRedirects": 5,
"unblocker": true,
"validate": {
"status": { "fail": [403, 503] },
"data": { "fail": ["Access Denied", "captcha"] }
}
}'
Das folgt bis zu fünf Weiterleitungen und prüft dann die finale Response. Wenn die Seite dich auf eine Verifizierungsseite oder eine Access-Denied-Wall weiterleitet, schlägt der Request sauber fehl. Keine fehlerhaften Daten, die du downstream herausfiltern musst.
Kombiniere für die Binärdatenerfassung returnBuffer mit HEAD-Requests, wenn du Content-Types vor dem Download großer Dateien prüfen musst. FourA verarbeitet HEAD korrekt, sodass du Header ohne Abruf des Body inspizieren kannst. Prüfe den Content-Type, entscheide, ob sich der Download lohnt, und führe dann den vollständigen Request mit returnBuffer: true aus.
Falls du Browser-Tasks für JavaScript-lastige Ziele nutzt: Diese Optionen gelten für die direkte HTTP-Engine. Browser-Requests verarbeiten Weiterleitungen über die integrierte Browser-Navigation, die ihnen standardmäßig ohne Limit folgt.
Was kommt als Nächstes
Wir arbeiten daran, mehr Kontrollmöglichkeiten auf Request-Ebene über die API bereitzustellen: benutzerdefinierte DNS-Auflösung, Timeout-Tuning pro Phase und Optionen zur Zertifikatsbehandlung. Das Ziel ist die vollständige Kontrolle über Browser-Profile über eine saubere REST-Schnittstelle, ganz ohne Infrastruktur-Overhead.
Wenn du eine bestimmte Option benötigst, freuen wir uns auf Feedback. Das Dashboard zeigt bereits, wie deine Requests mit diesen neuen Optionen abschneiden, sodass du den Unterschied selbst messen kannst.