Also User Agent habe ich schon eingestellt. Den selben, den ich habe. Ich kann die Seite normal per Browser öffnen, aber sie lässt sich mit keinem Crawler öffnen. Auch Suchmaschinen Seiten wie zB woorank.com kann kein Foto der Seite erstellen. Ich würde echt zu gerne wissen, wie die das machen.
✔ Crawler Probleme
- Themenstarter Tommy57
- Beginndatum
mermshaus
Erfahrenes Mitglied
Neben dem User-Agent Header gibt es natürlich noch weitere Header, die abgeprüft werden könnten.
Ein naheliegender Kandidat wäre noch Accept-Encoding. Das muss nicht mal aktiv auf der Absicht gründen, Leute auszuschließen. Es könnte sein, dass die Seite einfach nur noch gepackt übertragen wird. Wenn der Client (in dem Fall curl) dann nicht darüber informiert, dass das unterstützt wird, kommt möglicherweise nichts. In diesem Fall etwa per:
Eine empfehlenswerte Library (konkret ein Wrapper um cURL) für HTTP-Requests in PHP: http://docs.guzzlephp.org/en/stable/
Ein naheliegender Kandidat wäre noch Accept-Encoding. Das muss nicht mal aktiv auf der Absicht gründen, Leute auszuschließen. Es könnte sein, dass die Seite einfach nur noch gepackt übertragen wird. Wenn der Client (in dem Fall curl) dann nicht darüber informiert, dass das unterstützt wird, kommt möglicherweise nichts. In diesem Fall etwa per:
Code:
Accept-Encoding: gzipEine empfehlenswerte Library (konkret ein Wrapper um cURL) für HTTP-Requests in PHP: http://docs.guzzlephp.org/en/stable/
Vielen Dank mermshaus. Tatsächlich. Ich kann durch das gzip die Seite nun aufrufen. Aber komischerweise nur vom localhost. Starte ich das selbe Script vom Server, krieg ich wieder die Fehlerseite. Eine Idee, woran das liegen kann?
EDIT: Was ist denn an dem Guzzle besser bzw anders als an cURL?
EDIT: Was ist denn an dem Guzzle besser bzw anders als an cURL?
Zuletzt bearbeitet:
mermshaus
Erfahrenes Mitglied
Es ist nicht unwahrscheinlich, dass es weiterhin an Headern liegt, die etwas verschieden gesetzt werden zwischen dem PHP auf localhost und dem PHP auf dem Server.
So was ist in gewisser Weise wahrscheinlich von der konkreten PHP-Version/-Konfiguration oder auch cURL-Version abhängig. Ich würde mir mal die Header anschauen, mit denen es funktioniert, und die dann nachbauen und – falls es dann geht – gegebenenfalls versuchen, unnötig erscheinende Header nachträglich rauszunehmen und zwischendurch immer wieder zu testen.
Etwa im Browser kannst du mit den Entwicklertools (F12) sehen, mit welchen Headern der Browser die Seite aufruft. Das wäre ein guter Startpunkt.
Guzzle ist eine Abstraktion der mitunter sperrigen curl-Aufrufe und -Logik. Die Syntax ist zum Beispiel wesentlich lesbarer. Auch übernimmt Guzzle auf elegante Weise so was wie das Verwalten und MItsenden von Cookies.
Das wäre ein (schematisches) Beispiel-Snippet für einen Login mit nachträglichem Abrufen einer durch Login gesicherten Seite.
Auch das Verarbeiten der gelieferten Daten ist simpler als von Hand, weil Guzzle sich um die Protokolldetails kümmert (etwa gzip-Encoding).
So was ist in gewisser Weise wahrscheinlich von der konkreten PHP-Version/-Konfiguration oder auch cURL-Version abhängig. Ich würde mir mal die Header anschauen, mit denen es funktioniert, und die dann nachbauen und – falls es dann geht – gegebenenfalls versuchen, unnötig erscheinende Header nachträglich rauszunehmen und zwischendurch immer wieder zu testen.
Etwa im Browser kannst du mit den Entwicklertools (F12) sehen, mit welchen Headern der Browser die Seite aufruft. Das wäre ein guter Startpunkt.
Guzzle ist eine Abstraktion der mitunter sperrigen curl-Aufrufe und -Logik. Die Syntax ist zum Beispiel wesentlich lesbarer. Auch übernimmt Guzzle auf elegante Weise so was wie das Verwalten und MItsenden von Cookies.
PHP:
$guzzle = new \GuzzleHttp\Client([
'base_uri' => 'https://www.example.org/',
'cookies' => true,
'headers' => [
'Accept-Encoding' => 'gzip',
]
]);
$guzzle->post('community/login', [
'form_params' => [
'username' => $username,
'password' => $password,
'target' => 'index?login=1',
'doLogin' => 'Login'
]
]);
$response = $guzzle->get('profile/index');
$html = $response->getBody()->getContents();Das wäre ein (schematisches) Beispiel-Snippet für einen Login mit nachträglichem Abrufen einer durch Login gesicherten Seite.
Auch das Verarbeiten der gelieferten Daten ist simpler als von Hand, weil Guzzle sich um die Protokolldetails kümmert (etwa gzip-Encoding).
Hi,
könnte auch sein, dass die andere Seite eine IP-Blacklist hat mit denen die bekannte grössere Serverhoster aussortieren (OVH, 1&1, Hetzner etc.)
Andere Möglichkeit wäre, dass sie regelmässig Logs scannen, auffällige Zugriffsmuster erkennen und die IPs dann sperren.
Etwas OffTopic: Anscheinend will die andere Seite nicht, dass du deren Inhalt (Copyright?) regelmässig abrufst. Gibt es auch eine robots.txt Datei bei denen? Mal nachfragen ob du das überhaupt darfst?
Grüsse,
BK
// Edit: Gerade selbst probiert:
Daheim: OK
Von Hetzner Server: Geht nicht
Von OVH Server: Geht nicht
könnte auch sein, dass die andere Seite eine IP-Blacklist hat mit denen die bekannte grössere Serverhoster aussortieren (OVH, 1&1, Hetzner etc.)
Andere Möglichkeit wäre, dass sie regelmässig Logs scannen, auffällige Zugriffsmuster erkennen und die IPs dann sperren.
Etwas OffTopic: Anscheinend will die andere Seite nicht, dass du deren Inhalt (Copyright?) regelmässig abrufst. Gibt es auch eine robots.txt Datei bei denen? Mal nachfragen ob du das überhaupt darfst?
Grüsse,
BK
// Edit: Gerade selbst probiert:
Bash:
curl -H 'Accept-Encoding: gzip' \
-H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0' \
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' \
-H 'Accept-Language: en-US,en;q=0.5' \
http://www.sothebys.com/en.htmlVon Hetzner Server: Geht nicht
Von OVH Server: Geht nicht
Zuletzt bearbeitet:
