Differenza tra `curl -I` e` curl -X HEAD`

Stavo guardando il tipo di server divertente da http://www.reddit.com con curl -I http://www.reddit.com quando ho indovinato che curl -X HEAD http://www.reddit.com avrebbe fatto il stesso. Ma, infatti, non lo fa.

Sono curioso di perché.

Questo è ciò che osservo eseguendo i due comandi:

  • curl -I : funziona come previsto, emette l'intestazione ed esiste.

  • curl -X HEAD : non mostra nulla e sembra aspettare l'input dell'utente.

Ma sniffing con tshark vedo che il secondo command effettivamente invia la stessa query HTML e riceve la risposta corretta, ma non lo mostra e non chiude la connessione.

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 

Qualche idea di perché questa differenza nel comportmento?

  • Come submit le intestazioni Content-Disposition in apache per i file?
  • Obfuscazione del field server di un'intestazione di risposta HTTP
  • Nginx - Consentire le richieste senza un'intestazione host
  • nginx add_header non funziona in una delle mie posizioni
  • Caching di proxy di Nginix - come controllare se funziona?
  • Intestazione server NGINX Pass-through
  • Rimuovere la versione "X-Page-Speed" dalle intestazioni in ngx_pagespeed
  • Impostazioni dell'intestazione di controllo della cache di IIS
  • 4 Solutions collect form web for “Differenza tra `curl -I` e` curl -X HEAD`”

    Sembra che la differenza ha a che fare con l'intestazione Content-Length e come viene trattata da entrambi i comandi.

    Ma prima di andare in questo, il curl -X HEAD non fornisce alcuna output perché, per impostazione predefinita, la curl non printing le intestazioni se l'interruttore -i non è fornito (non è necessario su -I anche se).

    In each caso, curl -I è il modo corretto per recuperare le intestazioni. Basta chiedere l'intestazione e chiudere la connessione.

    D'altra parte curl -X HEAD -i attende la trasmissione del numero di byte dichiarati da Content-Length . Nel caso in cui non sia specificata nessuna Content-Length , indovino che attenderà alcuni dati o per quella particolare intestazione.

    Alcuni esempi che mostrano questo comportmento:

     $ 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 

    Poiché Content-Length è 0, in questo caso entrambi i comandi si comportno nello stesso modo. E la connessione è chiusa in seguito.

     $ 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 questo caso, sembra che ci sia un timeout (probabilmente da Vernice), quindi protesta la connessione che la connessione è stata chiusa prima di aver ricevuto il numero di byte Content-Length .

    A proposito, guarda il divertente X-Bender (mostrato nell'esempio) e X-Fry (prova per te) le intestazioni :).

    Penso che questo sia un bug in curl. Se specifico un metodo con -X, curl dovrebbe gestire la risposta in base al RFC. Purtroppo, il mantenitore di curl non è d'accordo. Qualcuno ha presentato un bug e ha anche presentato una patch:

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

    ma il curatore ha rifiutato. A quanto pare un'opzione rotta "-X HEAD" è "funzionante come progettato".

    –Jamshid

    Dai documenti :

    -X, – domanda

    (HTTP) Specifica un metodo di richiesta personalizzato da utilizzare quando si comunica con il server HTTP. Il metodo di richiesta specificato verrà utilizzato al posto del metodo diverso utilizzato (il cui valore predefinito è GET). Leggere la specifica HTTP 1.1 per dettagli e spiegazioni. Ulteriori richieste HTTP comuni includono PUT e DELETE, ma le tecnologie correlate come WebDAV offrono PROPFIND, COPIA, MOVE e altro ancora.

    Normalmente non è necessaria questa opzione. Tutte le richieste di GET, HEAD, POST e PUT sono piuttosto invocate utilizzando opzioni dedicate alla row di command.

    Questa opzione modifica solo la parola effettiva utilizzata nella richiesta HTTP, non altera il modo in cui il curl si comport . Quindi, per esempio, se si desidera effettuare una richiesta HEAD corretta, utilizzare -X HEAD non è sufficiente. È necessario utilizzare l'opzione -I, -head.

    In altre parole, -X è per i methods diversi da GET , HEAD , POST e PUT . Per HEAD utilizzare -I .

    Conosco lo stesso problema quando scrivo codice cpp sulla curl 7.34,

     curl_easy_setopt(curl_handle, CURLOPT_CUSTOMREQUEST, "HEAD"); 

    ci appenderà da molto tempo, sembra che sta aspettando il trasferimento del corpo fino a quando non accada un timeout. dopo aver aggiunto una nuova linea, questo problema viene risolto.

     curl_easy_setopt(curl_handle, CURLOPT_NOBODY, 1L ); 

    dal doc

    fare la richiesta di download senza get il corpo

    questa linea avrebbe costretto l'arricciarsi a non aspettare.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.