Vraag Verschil tussen `curl -I` en` curl -X HEAD`


Ik keek naar het grappige servertype http://www.reddit.com met curl -I http://www.reddit.com toen ik dat geraden had curl -X HEAD http://www.reddit.com zou hetzelfde doen. Maar dat is het ook niet.

Ik ben benieuwd waarom.

Dit is wat ik observeer met de twee commando's:

  • curl -I: werkt zoals verwacht, geeft de header uit en bestaat.

  • curl -X HEAD: toont niets en lijkt te wachten op gebruikersinvoer.

Maar snuiven met tshark Ik zie dat het tweede commando feitelijk dezelfde HTML-vraag verzendt en het juiste antwoord ontvangt, maar het wordt niet getoond en het sluit de verbinding niet.

curl -I

0.000000 333.33.33.33 -> 213.248.111.106 TCP 59675 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=47267342 TSER=0 WS=6
0.045392 213.248.111.106 -> 333.33.33.33 TCP http > 59675 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=2552532839 TSER=47267342 WS=1
0.045441 333.33.33.33 -> 213.248.111.106 TCP 59675 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=47267353 TSER=2552532839
0.045623 333.33.33.33 -> 213.248.111.106 HTTP HEAD / HTTP/1.1
0.091665 213.248.111.106 -> 333.33.33.33 TCP http > 59675 [ACK] Seq=1 Ack=155 Win=6432 Len=0 TSV=2552532886 TSER=47267353
0.861782 213.248.111.106 -> 333.33.33.33 HTTP HTTP/1.1 200 OK
0.861830 333.33.33.33 -> 213.248.111.106 TCP 59675 > http [ACK] Seq=155 Ack=321 Win=6912 Len=0 TSV=47267557 TSER=2552533656
0.862127 333.33.33.33 -> 213.248.111.106 TCP 59675 > http [FIN, ACK] Seq=155 Ack=321 Win=6912 Len=0 TSV=47267557 TSER=2552533656
0.910810 213.248.111.106 -> 333.33.33.33 TCP http > 59675 [FIN, ACK] Seq=321 Ack=156 Win=6432 Len=0 TSV=2552533705 TSER=47267557
0.910880 333.33.33.33 -> 213.248.111.106 TCP 59675 > http [ACK] Seq=156 Ack=322 Win=6912 Len=0 TSV=47267570 TSER=2552533705

curl -X HEAD

34.106389 333.33.33.33 -> 213.248.111.90 TCP 51690 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=47275868 TSER=0 WS=6
34.149507 213.248.111.90 -> 333.33.33.33 TCP http > 51690 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=3920268348 TSER=47275868 WS=1
34.149560 333.33.33.33 -> 213.248.111.90 TCP 51690 > http [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=47275879 TSER=3920268348
34.149646 333.33.33.33 -> 213.248.111.90 HTTP HEAD / HTTP/1.1
34.191484 213.248.111.90 -> 333.33.33.33 TCP http > 51690 [ACK] Seq=1 Ack=155 Win=6432 Len=0 TSV=3920268390 TSER=47275879
34.192657 213.248.111.90 -> 333.33.33.33 TCP [TCP Dup ACK 15#1] http > 51690 [ACK] Seq=1 Ack=155 Win=6432 Len=0 TSV=3920268390 TSER=47275879
34.823399 213.248.111.90 -> 333.33.33.33 HTTP HTTP/1.1 200 OK
34.823453 333.33.33.33 -> 213.248.111.90 TCP 51690 > http [ACK] Seq=155 Ack=321 Win=6912 Len=0 TSV=47276048 TSER=3920269022

Enig idee over waarom dit verschil in gedrag?


54
2018-05-10 08:49


oorsprong


Zie ook daniel.haxx.se/blog/2015/09/11/unnecessary-use-of-curl-x - Abbafei


antwoorden:


Het lijkt erop dat het verschil te maken heeft met de Content-Length header en hoe deze wordt behandeld door beide opdrachten.

Maar voordat je daar op ingaat, curl -X HEAD geeft geen uitvoer omdat, standaard, curl drukt geen headers af als schakelaar -i is niet voorzien (niet nodig op -I wel).

In elk geval, curl -I is de juiste manier om de headers op te halen. Het vraagt ​​gewoon om de header en sluit de verbinding.

Anderzijds curl -X HEAD -i zal wachten op de verzending van het aantal bytes vermeld door Content-Length. In geval nr Content-Length is niet gespecificeerd, ik vermoed dat het zal wachten op sommige gegevens of voor die specifieke header.

Enkele voorbeelden van dit gedrag:

$ curl -X HEAD -i http://www.elpais.es
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: http://www.elpais.com/
Date: Wed, 12 May 2010 06:35:57 GMT
Connection: keep-alive

Omdat Content-Length is 0, in dit geval gedragen beide commando's zich hetzelfde. En de verbinding is achteraf gesloten.

$ curl -X HEAD -i http://slashdot.org
HTTP/1.1 200 OK
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001296
X-Bender: Since I love you all so much, I'd like to give everyone hugs.
X-XRDS-Location: http://slashdot.org/slashdot.xrds
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=iso-8859-1
Content-Length: 115224
Date: Wed, 12 May 2010 06:37:20 GMT
X-Varnish: 1649060825 1649060810
Age: 1
Connection: keep-alive

curl: (18) transfer closed with 115224 bytes remaining to read

In dit geval lijkt er sprake te zijn van een time-out (waarschijnlijk door Varnish), dus curl protesteert dat de verbinding werd gesloten voordat de Content-Length aantal bytes.

Kijk trouwens naar de grappige X-Bender (getoond in het voorbeeld) en X-Fry (probeer het zelf) koppen :).


53
2018-05-12 06:49



In het geval dat iemand anders dit zoekt: de optie om in de Curl-bibliotheek van PHP in te stellen is CURLOPT_NOBODY. - Matthew Caruana Galizia


Ik denk dat dit een fout in de krul is. Als ik een methode met -X opgeeft, moet curl het antwoord verwerken volgens de RFC. Helaas is de beheerder van curl het daar niet mee eens. Iemand heeft een bug ingediend en heeft zelfs een patch ingediend:

http://sourceforge.net/tracker/?func=detail&atid=100976&aid=1810273&group_id=976

maar de curl-beheerder wees het af. Blijkbaar is een kapotte "-X HOOFD" optie "werken zoals ontworpen".

--Jamshid


12
2018-03-29 20:59



Om eerlijk te zijn, kan ik de logica volgen van de reactie van het ticket: --head biedt ons een geldige implementatie van een HEAD-verzoek, en -X <method> gewoon overschrijft de HTTP-methode in het verzoek. - Hank
ja, dit was eigenlijk wat ik nodig had. Ik heb een buggy-server die inhoud serveert wanneer een HEAD-verzoek wordt gegeven. -X HEAD was de enige manier om het te testen wanneer ik probeerde de server aan te sluiten bij de RFC - Hashbrown


Van de documenten:

-X, - aanvraag

(HTTP) Specificeert een aangepaste aanvraagmethode om te gebruiken bij communicatie met de HTTP-server. De opgegeven verzoekmethode wordt gebruikt in plaats van de methode die anders wordt gebruikt (die standaard GET gebruikt). Lees de HTTP 1.1-specificatie voor meer informatie en uitleg. Veelvoorkomende extra HTTP-verzoeken zijn PUT en DELETE, maar gerelateerde technologieën zoals WebDAV bieden PROPFIND, COPY, MOVE en meer.

Normaal heb je deze optie niet nodig. Allerlei GET-, HEAD-, POST- en PUT-verzoeken worden nogal aangeroepen door speciale opdrachtregelopties te gebruiken.

Deze optie verandert alleen het eigenlijke woord gebruikt in het HTTP-verzoek verandert niets aan de manier waarop krullen zich gedragen. Dus als u bijvoorbeeld een goede HEAD-aanvraag wilt doen, is het gebruik van -X HEAD niet voldoende. U moet de optie -I, --head gebruiken.

Met andere woorden, -X is voor andere methoden dan GET, HEAD, POST en PUT. Voor HEAD gebruik -I.


2
2018-03-02 07:36





Ik ontmoet hetzelfde probleem bij het schrijven van cpp-code op krul 7.34,

curl_easy_setopt(curl_handle, CURLOPT_CUSTOMREQUEST, "HEAD");

zal daar lang blijven hangen, lijkt te wachten op lichaamstransfer totdat een time-out optreedt. na het toevoegen van een nieuwe regel is dit probleem opgelost.

curl_easy_setopt(curl_handle, CURLOPT_NOBODY, 1L );

van het document

voer het downloadverzoek uit zonder het lichaam te bemachtigen

deze lijn dwingt krul om niet te wachten.


0
2017-07-19 08:42