Redirect-Ketten machen Scraper kaputt. Binäre Responses korrumpieren, wenn sie als Text decodiert werden. 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 bewältigen: followRedirects und returnBuffer. Sie sind jetzt in der API live.
Wie es funktioniert
Redirect-Steuerung mit followRedirects
Die meisten Scraping-APIs behandeln Redirects als Boolean: folgen oder nicht. Das funktioniert, bis du auf eine Redirect-Kette triffst, die in einer Schleife hängt, oder du die zwischenzeitliche 302-Response selbst brauchst, um einen Tracking-Parameter zu extrahieren.
followRedirects von FourA nimmt einen Integer zwischen 0 und 20. Lass es weg (oder setze 0), und du bekommst die rohe Redirect-Response zurück, inklusive Header und allem. Setze es auf 5, und der Request folgt bis zu fünf Hops, bevor er zurückgibt, wo er gelandet ist.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/short-link",
"followRedirects": 3,
"unblocker": true
}'
Dies folgt bis zu drei Redirects. Wenn sich die Kette in zwei auflöst, bekommst du die finale Seite. Wenn sie länger als drei ist, bekommst du das, was der dritte Hop zurückgegeben hat.
Der Unterschied ist wichtiger als du denkst. E-Commerce-Websites leiten über Tracking-URLs um, bevor sie auf der Produktseite landen. Du willst diesen folgen. Aber Affiliate-Netzwerke und URL-Shortener erzeugen manchmal Ketten, die sechs, sieben oder acht Hops tief gehen. Und manche Redirect-Schleifen lösen sich nie auf. Die Begrenzung auf eine bestimmte Zahl bedeutet, dass du Daten sammelst, ohne in einer Endlosschleife festzustecken, die dein Request-Timeout verbraucht.
Vorher war der Workaround, einen Request mit deaktivierten Redirects zu senden, den Location-Header manuell zu parsen und einen weiteren Request zu senden. Das sind mindestens zwei API-Aufrufe, doppelte Latenz und Code, den du pflegen musst. Jetzt ist es ein Aufruf mit einer Zahl.
Rohe binäre Responses mit returnBuffer
Wenn du Bilder, PDFs oder Protobuf-Payloads sammelst, zerstört Text-Decodierung die Daten. Die HTTP-Bibliothek geht davon aus, dass die Response Text ist, wendet Charset-Erkennung an und verunstaltet stillschweigend jedes Byte, das nicht passt. Protobuf wird unlesbar. Image-Header gehen kaputt. Du endest mit korrupten Dateien und ohne offensichtliche Fehlermeldung, die erklärt, warum.
returnBuffer sagt der API, dass sie die Text-Decodierung komplett überspringen soll.
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product-image.jpg",
"returnBuffer": true
}'
Der Response-Body kommt als rohe Bytes zurück (Base64-codiert in JSON-Responses). Decodiere es auf deiner Seite und du hast genau das, was der Server gesendet hat. Keine Charset-Annahmen, keine Encoding-Konvertierung, keine stille Korruption.
Das war eines der häufigeren Support-Tickets, die wir gesehen haben: Nutzer, die Produktbilder oder PDF-Kataloge sammelten und Dateien bekamen, die sich nicht öffnen ließen. Der Fix war immer derselbe, aber jetzt gibt es ein Flag dafür anstelle eines Workarounds.
Auswirkungen
Beide Features reduzieren die Anzahl der API-Aufrufe pro Job. followRedirects eliminiert manuelle Redirect-Verfolgungsschleifen. returnBuffer eliminiert den Zyklus aus Abrufen, Feststellen von Korruption und erneutem Abrufen mit anderen Einstellungen.
Bei Redirect-lastigen Zielen (Affiliate-Links, URL-Shortener, E-Commerce-Tracking-Ketten) haben wir in frühen Tests einen Rückgang der Request-Zahlen um 40 bis 60 Prozent gesehen, wenn Nutzer vom manuellen Redirect-Handling zu followRedirects wechseln. Und für binäre Sammelaufgaben (Produktbilder, Dokumenten-Downloads) macht returnBuffer aus einem mehrstufigen Workaround eine einzelne Option (frühe Ergebnisse).
Das sind keine auffälligen Features. Es sind die Dinge, über die du nicht nachdenkst, bis dein Scraper um 3 Uhr morgens abbricht, weil eine Seite einen zusätzlichen Redirect-Hop zu ihrem Checkout-Flow hinzugefügt hat.
Für Power-User
Kombiniere followRedirects mit Response-Validierung für präzise Kontrolle über Redirect-Ketten. Folge Redirects, aber lass den Request fehlschlagen, wenn das finale Ziel auf eine Wand trifft:
curl -X POST "https://eu.api.foura.ai/v1/request" \
-H "Authorization: Bearer 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"] }
}
}'
Dies folgt bis zu fünf Redirects und prüft dann die finale Response. Wenn die Seite dich auf eine CAPTCHA-Seite oder eine Access-Denied-Wand umgeleitet hat, schlägt der Request sauber fehl. Keine Mülldaten, die du später herausfiltern musst.
Für die binäre Sammlung kombinierst du returnBuffer mit HEAD-Requests, wenn du Content-Types prüfen musst, bevor du große Dateien herunterlädst. FourA behandelt HEAD korrekt, sodass du Header inspizieren kannst, ohne den Body abzurufen. Prüfe den Content-Type, entscheide, ob sich der Download lohnt, und mache dann den vollen Request mit returnBuffer: true.
Und wenn du Browser-Tasks für JavaScript-lastige Ziele verwendest, beachte, dass diese Optionen für die direkte HTTP-Engine gelten. Browser-Requests behandeln Redirects über die integrierte Navigation des Browsers, die ihnen standardmäßig ohne Limit folgt.
Was kommt als Nächstes
Wir arbeiten daran, mehr Kontrollen auf Request-Ebene über die API freizugeben: benutzerdefinierte DNS-Auflösung, Timeout-Tuning pro Phase und Optionen für die Zertifikatsbehandlung. Das Ziel ist die volle Unblocker-Power über ein sauberes REST-Interface, ohne den Infrastruktur-Overhead.
Wenn es eine spezifische Option gibt, die du brauchst, hören wir zu. Das Dashboard zeigt bereits, wie deine Requests mit diesen neuen Optionen performen, sodass du den Unterschied selbst messen kannst.