Warum hat LOCKE nicht, aber wget funktioniert?

Ich bin mit beiden curl " und "wget", um diese url: http://opinionator.blogs.nytimes.com/2012/01/19/118675/

Für curl, es gibt keine Ausgabe, sondern mit wget gibt es den gesamten HTML-Quelltext:

Hier sind die 2 Befehle. Ich habe die gleiche Benutzer-agent, und beide kommen von der gleichen IP, und folgenden Umleitungen. Die URL ist genau die gleiche. Für LOCKE gibt es sofort nach 1 Sekunde, so dass ich weiß, dass es nicht zu einem timeout-Problem.

curl -L -s "http://opinionator.blogs.nytimes.com/2012/01/19/118675/" --max-redirs 10000 --location --connect-timeout 20 -m 20 -A "Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" 2>&1

wget http://opinionator.blogs.nytimes.com/2012/01/19/118675/--user-agent="Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"

Wenn NY Times könnte cloaking, und nicht wieder die Quelle zu kräuseln, was anders sein könnte in den Header, curl sendet? Ich nahm an, da der user-agent ist der gleiche, der Antrag sollte genau gleich Aussehen von diesen beiden Anfragen. Was andere "footprints" sollte ich überprüfen?

  • diese würde Ihnen helfen? stackoverflow.com/questions/8298727/...
  • nicht helpt an alle 🙁
  • Ich schlage vor hinzufügen der -v - flag zu Ihren curl Anfrage, Ihnen zu zeigen, alles, was Los ist. Die -d flag Hinzugefügt, um Ihre wget-Anfrage zeigt Sie, was geschieht mit der erfolgreichen wget-Anfrage. Beide Programme werden umgeleitet auf eine login-Seite, aber irgendwie wget erfolgreich ruft die Ziel-Ressource, sondern curl ist ständig umgeleitet, bis es bekommt einen schlechten Umleitung und gibt auf. Nach einem kurzen Blick auf die Ausgabe, es sieht aus wie wget ist richtig senden von cookies zurück nytimes.com beim curl ist nie senden von cookies zurück.
  • Versuchen Sie es mit -c cookie.txt mit Ihrem curl und Optional -b RMID.
  • Vielen Dank, das senden von cookies funktioniert. Was bedeutet -b RMID tun?
  • Es erzwingt das senden einer leeren RMID cookie.

InformationsquelleAutor Henley Chiu | 2014-01-08
  1. 13

    Dem Weg zu lösen, ist die Analyse Ihrer curl Anfrage durch tun curl -v ... und Ihre Anfrage per wget zu tun wget -d ... was zeigt, dass curl ist umgeleitet auf eine login-Seite

    > GET /2012/01/19/118675/HTTP/1.1
> User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
> Host: opinionator.blogs.nytimes.com
> Accept: */*
> 
< HTTP/1.1 303 See Other
< Date: Wed, 08 Jan 2014 03:23:06 GMT
* Server Apache is not blacklisted
< Server: Apache
< Location: http://www.nytimes.com/glogin?URI=http://opinionator.blogs.nytimes.com/2012/01/19/118675/&OQ=_rQ3D0&OP=1b5c69eQ2FCinbCQ5DzLCaaaCvLgqCPhKP
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8

    gefolgt von einer Schleife von Umleitungen (die Sie wohl bemerkt haben, denn Sie haben bereits die --max-redirs flag).

    Auf der anderen Seite wget folgt der gleichen Reihenfolge, außer dass es gibt die cookie-set von nytimes.com mit Ihrer anschließenden Anfrage(N)

    ---request begin---
GET /2012/01/19/118675/?_r=0 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: */*
Host: opinionator.blogs.nytimes.com
Connection: Keep-Alive
Cookie: NYT-S=0MhLY3awSMyxXDXrmvxADeHDiNOMaMEZFGdeFz9JchiAIUFL2BEX5FWcV.Ynx4rkFI

    Die Anfrage gesendet durch curl, enthält niemals den Keks.

    Der einfachste Weg, ich sehe Sie zum ändern der curl-Befehl und erhalten Sie die gewünschte Ressource ist, indem -c cookiefile Ihren curl-Befehl. Dieser speichert das cookie in die ansonsten unbenutzten temporären "cookie-jar" - Datei namens "cookiefile" damit LOCKE zu senden, die erforderlich cookie(s) mit nachfolgenden Anforderungen.

    Zum Beispiel, habe ich noch die Flagge -c x direkt nach "curl" und ich bekam die Ausgabe, so wie bei wget (außer, dass wget schreibt es in eine Datei und curl gibt diese auf STDOUT).

    • -v ist in der Regel sehr hilfreich
    InformationsquelleAutor Joseph Myers
Schreibe einen Kommentar