3
Über Konsole Webseite auslesen
Hi, ich möchte gerne per Konsole den Quelltext einer Webseite auslesen. Leider scheitere ich daran. Ausprobiert habe ich bis jetzt folgendes:
1) Verbindung auf bauen zu http://URL.com auf Port 80und speichert . Das klappt, Verbindung steht. Rückmeldung vom Server kommt gar nichts.
2) Ich sende: GET /Webseite.php?id=321
(Keine Antwort, Verbindung bleibt)
3) ich sende irgendetwas (was der Server wohl nicht versteht. Kann auch "host: URL.com" sein oder "user-agent: mozilla"). Antwort:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 17 Jul 2020 20:58:34 GMT
Content-Type: text/html
Content-Length: 150
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
4) ich ärgere mich
Also: irgendwas mache ich TOTAL falsch! Und natürlich google ich seit Stunden schon herum. Aber ich werde einfach nicht klug genug, um die richtigen Befehle in richtiger Reihenfolge zu senden...
Achso: ich hab verschiedene TCP Clients ausprobiert und auch Telnet. Auch welche auf nem Android Handy.
Hintergrund:
Auf dem Server habe ich eine kurze PHP Seite liegen, die Werte ausliest (id z.b. deswegen ist das ?id=321 auch so wichtig) und in eine Textdatei schreibt. Per echo gibt es dann ein ok. Alles nicht perfekt gemacht, ich weiß. Aber ich kapier nicht, warum ich die URL http://url.com/Webseite.php?id=321 per Browser aufrufen kann und alles geht. Aber ich das nicht über nen TCP Client hinbekomme!
Ich verzweifel grad!
Danke!
1) Verbindung auf bauen zu http://URL.com auf Port 80und speichert . Das klappt, Verbindung steht. Rückmeldung vom Server kommt gar nichts.
2) Ich sende: GET /Webseite.php?id=321
(Keine Antwort, Verbindung bleibt)
3) ich sende irgendetwas (was der Server wohl nicht versteht. Kann auch "host: URL.com" sein oder "user-agent: mozilla"). Antwort:
HTTP/1.1 400 Bad Request
Server: nginx
Date: Fri, 17 Jul 2020 20:58:34 GMT
Content-Type: text/html
Content-Length: 150
Connection: close
<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
4) ich ärgere mich
Also: irgendwas mache ich TOTAL falsch! Und natürlich google ich seit Stunden schon herum. Aber ich werde einfach nicht klug genug, um die richtigen Befehle in richtiger Reihenfolge zu senden...
Achso: ich hab verschiedene TCP Clients ausprobiert und auch Telnet. Auch welche auf nem Android Handy.
Hintergrund:
Auf dem Server habe ich eine kurze PHP Seite liegen, die Werte ausliest (id z.b. deswegen ist das ?id=321 auch so wichtig) und in eine Textdatei schreibt. Per echo gibt es dann ein ok. Alles nicht perfekt gemacht, ich weiß. Aber ich kapier nicht, warum ich die URL http://url.com/Webseite.php?id=321 per Browser aufrufen kann und alles geht. Aber ich das nicht über nen TCP Client hinbekomme!
Ich verzweifel grad!
Danke!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 588569
Url: https://administrator.de/contentid/588569
Printed on: April 16, 2024 at 14:04 o'clock
3 Comments
Latest comment
Entweder direkt auf der Konsole per
oder via Powershell mit
Manuel
wgetinvoke-webrequestManuel
Wenn du TCP-Clients oder Sockets benutzt, musst du die Anfrage selbst erzeugen. Das setzt ein gewisses Verständnis vom HTTP-Protkoll voraus. Beispielsweise brauchst du einen Host-Header. Für Lern- und sonstige Studienzwecke ist das perfekt, aber produktiv würde ich da lieber ein Kommandozeilenwerkzeug nutzen, welches HTTP bereits unterstützt. wget wurde bereits genannt, curl ist auch eine gute Alternative.
Wir auch nicht, da keiner außer du weiß, was denn konkret versucht wurde. Sei doch so nett und ergänze mal ein paar Beispiele in deiner Frage. Sonst hat keiner eine Chance, konkret zu helfen.
Mit den vorliegenden Infos kann man dir nur zu einem entsprechenden HTTP-Client raten, also wget/curl wie bereits angesprochen. Wenn dort Probleme auftreten (was im Falle eines einfachen GET-Requests i.d.R. nicht auftreten sollte), bekommt man mit --verbose/-v mehr Infos.
Beispiel:
Hier siehst du die komplette Anfrage und Reaktion des Servers. Auch wenn z.B. mit dem TLS-Zertifikat (falls vorhanden) etwas nicht stimmen sollte, könnte man hier sehen, dass es abgelaufen/nicht vertrauenswürdig oder was auch immer ist.
Zitat von @LukePerry:
Aber ich werde einfach nicht klug genug, um die richtigen Befehle in richtiger Reihenfolge zu senden...
Aber ich werde einfach nicht klug genug, um die richtigen Befehle in richtiger Reihenfolge zu senden...
Wir auch nicht, da keiner außer du weiß, was denn konkret versucht wurde. Sei doch so nett und ergänze mal ein paar Beispiele in deiner Frage. Sonst hat keiner eine Chance, konkret zu helfen.
Mit den vorliegenden Infos kann man dir nur zu einem entsprechenden HTTP-Client raten, also wget/curl wie bereits angesprochen. Wenn dort Probleme auftreten (was im Falle eines einfachen GET-Requests i.d.R. nicht auftreten sollte), bekommt man mit --verbose/-v mehr Infos.
Beispiel:
$ curl --head -v "https://ecosia.org"
* Trying 3.126.203.7:443...
* TCP_NODELAY set
* Connected to ecosia.org (3.126.203.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=ecosia.org
* start date: Jul 19 09:05:32 2020 GMT
* expire date: Oct 17 09:05:32 2020 GMT
* subjectAltName: host "ecosia.org" matched cert's "ecosia.org"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55d59a684db0)
> HEAD / HTTP/2
> Host: ecosia.org
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 301
HTTP/2 301
< server: nginx/1.15.9
server: nginx/1.15.9
< date: Mon, 20 Jul 2020 07:19:15 GMT
date: Mon, 20 Jul 2020 07:19:15 GMT
< content-type: text/html
content-type: text/html
< content-length: 169
content-length: 169
< location: https://www.ecosia.org/
location: https://www.ecosia.org/
< x-ecosia-hiring: If you found this header, we could use your help planting trees with code! Check out https://jobs.lever.co/ecosia
x-ecosia-hiring: If you found this header, we could use your help planting trees with code! Check out https://jobs.lever.co/ecosia
<
* Connection #0 to host ecosia.org left intacHier siehst du die komplette Anfrage und Reaktion des Servers. Auch wenn z.B. mit dem TLS-Zertifikat (falls vorhanden) etwas nicht stimmen sollte, könnte man hier sehen, dass es abgelaufen/nicht vertrauenswürdig oder was auch immer ist.