ความแตกต่างระหว่าง `curl -I` และ` curl -X HEAD`


70

ฉันดูประเภทเซิร์ฟเวอร์ตลกจากhttp://www.reddit.comด้วยcurl -I http://www.reddit.comเมื่อฉันเดาว่าcurl -X HEAD http://www.reddit.comจะทำเช่นเดียวกัน แต่ในความเป็นจริงมันไม่ได้

ฉันอยากรู้ว่าทำไม

นี่คือสิ่งที่ฉันสังเกตเห็นการรันทั้งสองคำสั่ง:

  • curl -I: ใช้งานได้ตามที่คาดหวังส่งออกส่วนหัวและมีอยู่

  • curl -X HEAD: ไม่แสดงอะไรเลยและดูเหมือนว่าจะรอการป้อนข้อมูลของผู้ใช้

แต่การดมกลิ่นกับtsharkฉันเห็นคำสั่งที่สองส่งจริงแบบสอบถาม HTML และได้รับคำตอบที่ถูกต้อง แต่มันไม่แสดงและไม่ได้ปิดการเชื่อมต่อ

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

มีความคิดเกี่ยวกับสาเหตุที่แตกต่างในพฤติกรรมอย่างไร


คำตอบ:


66

ดูเหมือนว่าจะมีความแตกต่างเกี่ยวกับContent-Lengthส่วนหัวและวิธีปฏิบัติต่อคำสั่งทั้งสอง

แต่ก่อนที่จะเข้าสู่ที่curl -X HEADไม่ให้ผลผลิตใด ๆ เพราะโดยปกติcurlไม่พิมพ์ส่วนหัวของสวิทช์-iไม่ได้ให้ (ไม่จำเป็นต้อง-Iแม้ว่า)

ไม่ว่าในกรณีใดcurl -Iเป็นวิธีที่เหมาะสมในการดึงข้อมูลส่วนหัว แค่ขอส่วนหัวและปิดการเชื่อมต่อ

บนมืออื่น ๆจะรอสำหรับการส่งของจำนวนไบต์ที่ระบุไว้โดยcurl -X HEAD -i Content-Lengthในกรณีที่ไม่มีการContent-Lengthระบุฉันเดาว่ามันจะรอข้อมูลบางส่วนหรือส่วนหัวนั้น

ตัวอย่างบางส่วนที่แสดงพฤติกรรมนี้:

$ 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

เนื่องจากContent-Lengthเป็น 0 ในกรณีนี้ทั้งสองคำสั่งจะทำงานเหมือนกัน และการเชื่อมต่อจะปิดหลังจากนั้น

$ 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

ในกรณีนี้ดูเหมือนว่าจะมีการหมดเวลา (อาจใช้วานิช) ดังนั้นcurlการประท้วงจึงปิดการเชื่อมต่อก่อนที่จะได้รับContent-Lengthจำนวนไบต์

โดยวิธีการดูตลก X-Bender (แสดงในตัวอย่าง) และ X-Fry (ลองด้วยตัวคุณเอง) ส่วนหัว :)


2
ในกรณีที่คนอื่นมามองหานี้เลือกที่จะกำหนดในห้องสมุดขด PHP CURLOPT_NOBODYคือ
แมทธิว

12

ฉันคิดว่านี่เป็นข้อผิดพลาดในขด ถ้าฉันระบุวิธีด้วย -X, curl ควรจัดการการตอบสนองตาม RFC น่าเสียดายที่ผู้ดูแลขดไม่เห็นด้วย มีคนยื่นข้อผิดพลาดและส่งแพทช์:

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

แต่ผู้ดูแลม้วนงปฏิเสธมัน เห็นได้ชัดว่าตัวเลือก "-X HEAD" ที่เสียหายคือ "ทำงานตามที่ออกแบบมา"

--Jamshid


4
เพื่อความเป็นธรรมฉันสามารถทำตามตรรกะของการตอบสนองตั๋ว: --headทำให้เรามีการใช้งานที่ถูกต้องของคำขอ HEAD และ-X <method>เพียงแค่แทนที่วิธี HTTP ในคำขอ
แฮงค์

3
ใช่นี่คือสิ่งที่ฉันต้องการ ฉันมีเซิร์ฟเวอร์บั๊กกี้ที่แสดงเนื้อหาเมื่อได้รับคำขอ HEAD -X HEADเป็นวิธีเดียวที่ฉันสามารถทดสอบได้เมื่อพยายามให้เซิร์ฟเวอร์ปฏิบัติตาม RFC
Hashbrown

5

จากเอกสาร :

-X, - คำขอ

(HTTP) ระบุวิธีการร้องขอที่กำหนดเองเพื่อใช้เมื่อสื่อสารกับเซิร์ฟเวอร์ HTTP วิธีการร้องขอที่ระบุจะถูกนำมาใช้แทนวิธีอื่นที่ใช้ (ซึ่งเป็นค่าเริ่มต้นที่ GET) อ่านข้อกำหนด HTTP 1.1 สำหรับรายละเอียดและคำอธิบาย คำขอ HTTP ทั่วไปเพิ่มเติม ได้แก่ PUT และ DELETE แต่เทคโนโลยีที่เกี่ยวข้องเช่น WebDAV ให้บริการ PROPFIND, COPY, MOVE และอื่น ๆ

โดยปกติคุณไม่ต้องการตัวเลือกนี้ คำขอ GET, HEAD, POST และ PUT ทุกประเภทจะถูกเรียกใช้โดยใช้ตัวเลือกบรรทัดคำสั่งเฉพาะ

ตัวเลือกนี้เฉพาะการเปลี่ยนแปลงที่เกิดขึ้นจริงคำที่ใช้ในการร้องขอ HTTP มันไม่เปลี่ยนแปลงทางพฤติกรรมขด ตัวอย่างเช่นถ้าคุณต้องการที่จะทำการร้องขอ HEAD ที่เหมาะสมการใช้ -X HEAD จะไม่เพียงพอ คุณต้องใช้ตัวเลือก -I, --head

ในคำอื่น ๆ-Xสำหรับวิธีการอื่น ๆ กว่าGET, HEAD, และPOST PUTสำหรับการใช้งานHEAD-I


0

ฉันพบปัญหาเดียวกันเมื่อเขียนโค้ด cpp บน curl 7.34

curl_easy_setopt(curl_handle, CURLOPT_CUSTOMREQUEST, "HEAD");

จะวางไว้ที่นั่นเป็นเวลานานดูเหมือนว่ากำลังรอการถ่ายโอนร่างกายจนกว่าจะหมดเวลา หลังจากเพิ่มบรรทัดใหม่ปัญหานี้จะได้รับการแก้ไข

curl_easy_setopt(curl_handle, CURLOPT_NOBODY, 1L );

จากเอกสาร

ทำคำขอดาวน์โหลดโดยไม่ได้รับเนื้อหา

บรรทัดนี้จะบังคับให้ขดไม่ต้องรอ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.