ค้นหาส่วนหัว HTTP

5 จาก 2 การให้คะแนน

ค้นหาส่วนหัว HTTP เป็นเครื่องมือฟรีสำหรับดึงส่วนหัวการตอบกลับ HTTP ทั้งหมดที่ URL ส่งกลับมาเมื่อได้รับคำขอ GET ทั่วไป

ส่วนหัวการตอบกลับ HTTP คืออะไร?

ส่วนหัวการตอบกลับ HTTP คือข้อมูลเมตาที่เว็บเซิร์ฟเวอร์ส่งมาก่อนเนื้อหาการตอบกลับ เช่น หน้า HTML รูปภาพ หรือเอกสาร JSON ข้อมูลเหล่านี้บอกไคลเอนต์ว่าควรตีความ แคช เปลี่ยนเส้นทาง หรือรักษาความปลอดภัยให้การตอบกลับอย่างไร

โดยปกติ การตอบกลับ HTTP/1.x จะเริ่มด้วยบรรทัดสถานะ HTTP แล้วตามด้วยส่วนหัว ส่วน HTTP/2 และ HTTP/3 จะระบุสถานะที่เทียบเท่ากันไว้ในส่วนหัวเทียม :status ในทางเทคนิค บรรทัดสถานะของ HTTP/1.x แยกจากส่วนหัว แต่มักแสดงไว้ด้วยกันเพราะช่วยบอกว่าคำขอสำเร็จหรือไม่ สถานะ 200 หมายถึงส่งทรัพยากรกลับมาแล้ว ส่วน 301 หรือ 302 หมายถึงการเปลี่ยนเส้นทาง 404 หมายถึงไม่พบทรัพยากร และ 500 หมายถึงเกิดข้อผิดพลาดฝั่งเซิร์ฟเวอร์

ส่วนหัวอาจมาจากเซิร์ฟเวอร์ต้นทาง พร็อกซีย้อนกลับ หรือเครือข่ายนำส่งเนื้อหาอย่าง Cloudflare ระบบเหล่านี้อาจเพิ่มหรือลบส่วนหัวระหว่างส่งต่อการตอบกลับ ดังนั้นผลลัพธ์จึงอาจสะท้อนข้อมูลมากกว่าตัวแอปพลิเคชันที่สร้างหน้าเว็บ

ใช้เครื่องมือตรวจสอบส่วนหัว HTTP อย่างไร?

ป้อน URL แบบเต็มที่ต้องการตรวจสอบ รวมถึงสกีมา เช่น https://www.example.com/account เครื่องมือจะส่งคำขอ GET ทั่วไปจากเซิร์ฟเวอร์ของตน แล้วแสดงส่วนหัว HTTP ที่ได้รับจาก URL นั้น

หากต้องการเปรียบเทียบส่วนหัวการตอบกลับอย่างแม่นยำ ให้ใช้ URL แต่ละรูปแบบที่ต้องการตรวจสอบตามจริง ส่วนหัวของ http://example.com, https://example.com และ https://www.example.com อาจต่างกัน เพราะแต่ละที่อยู่อาจมีการเปลี่ยนเส้นทาง กฎแคช และการกำหนดค่าเซิร์ฟเวอร์เป็นของตัวเอง

รูปแบบการเขียน URL ก็มีผลต่อคำขอเช่นกัน:

  • เว้นวรรคไม่ใช่อักขระดิบที่ใช้ได้ใน URL โดยทั่วไปจึงต้องเข้ารหัสแบบเปอร์เซ็นต์ ซึ่งในพาธมักเขียนเป็น %20
  • ? ใช้เริ่มส่วนคิวรี ส่วน & และ = มักใช้ในการเข้ารหัสคิวรีแบบฟอร์ม แต่ไม่ได้ทำหน้าที่นี้ในสตริงคิวรีทุกแบบ
  • ชื่อโดเมนที่มีอักขระกำกับเสียงหรืออักขระนอกภาษาละตินจะได้รับการประมวลผลด้วย IDNA และแสดงเป็น ASCII A-label ซึ่งมักขึ้นต้นด้วย xn-- ส่วนอักขระในพาธโดยทั่วไปจะถูกเข้ารหัสเป็นไบต์ UTF-8 แล้วจึงเข้ารหัสแบบเปอร์เซ็นต์
  • ส่วนระบุภายในหน้าที่ขึ้นต้นด้วย # จะได้รับการจัดการโดยเบราว์เซอร์ และไม่ถูกส่งไปกับคำขอ HTTP
  • URL ไม่มีความยาวสูงสุดที่ใช้ร่วมกันได้ทุกระบบ URL ที่ยาวมากอาจถูกเซิร์ฟเวอร์ พร็อกซี หรือแอปพลิเคชันปฏิเสธ

อ่านผลส่วนหัว HTTP อย่างไร?

ตรวจสอบส่วนหัวที่เกี่ยวข้องกับปัญหาที่กำลังวิเคราะห์ ชื่อส่วนหัวไม่แยกตัวพิมพ์ใหญ่และเล็ก แต่ไวยากรณ์ภายในค่าของส่วนหัวอาจแยกตัวพิมพ์

ฟิลด์ในผลลัพธ์ ข้อมูลที่บอก
Location ปลายทางของการเปลี่ยนเส้นทาง โดยปกติจะแสดงพร้อมสถานะ 3xx
Content-Type ประเภทสื่อที่ส่งกลับมา เช่น text/html, application/json หรือ image/png
Content-Length ขนาดเนื้อหาการตอบกลับที่ประกาศไว้ หน่วยเป็นไบต์ เมื่อเซิร์ฟเวอร์ระบุค่านี้ การตอบกลับแบบแบ่งเป็นส่วนหรือสร้างขึ้นแบบไดนามิกอาจไม่มีส่วนหัวนี้
Cache-Control and Expires คำสั่งเกี่ยวกับการแคช และเวลาหมดอายุของการตอบกลับหากมีการระบุไว้
Age อายุที่คำนวณได้ของการตอบกลับในแคช นับตั้งแต่ถูกสร้างหรือตรวจสอบความถูกต้องครั้งล่าสุด โดยอาจรวมเวลาที่อยู่ในแคชต้นทาง ค่านี้แสดงเป็นวินาที
ETag and Last-Modified ตัวตรวจสอบที่ไคลเอนต์ใช้เช็กได้ว่าเนื้อหาในแคชมีการเปลี่ยนแปลงหรือไม่
Set-Cookie คำขอให้จัดเก็บคุกกี้ รวมถึงแอตทริบิวต์อย่าง Secure, HttpOnly และ SameSite
Content-Security-Policy กฎของเบราว์เซอร์ที่จำกัดว่าสคริปต์ สไตล์ เฟรม และทรัพยากรอื่นใดที่หน้าเว็บโหลดได้
Strict-Transport-Security คำสั่งให้เบราว์เซอร์ที่รองรับใช้ HTTPS เป็นระยะเวลาที่กำหนด

ส่วนหัวอื่นอาจใช้เฉพาะกับบางแอปพลิเคชัน ตัวอย่างเช่น Access-Control-Allow-Origin ใช้ควบคุมว่าต้นทางใดอ่านการตอบกลับผ่านคำขอข้ามต้นทางของเบราว์เซอร์ได้ ส่วนหัว Server อาจระบุชื่อซอฟต์แวร์หรือพร็อกซี แต่ใช้ยืนยันแพลตฟอร์มเบื้องหลังไม่ได้อย่างน่าเชื่อถือ เพราะผู้ดูแลระบบสามารถแก้ไขหรือลบค่านี้ได้

ตัวอย่างการแก้ปัญหาที่พบบ่อย

ปัญหาการเปลี่ยนเส้นทางเป็นเหตุผลหนึ่งที่พบบ่อยในการตรวจสอบส่วนหัว สมมติว่า https://example.com/old-page ส่งสถานะ 301 พร้อม Location: https://example.com/new-page หมายความว่าเซิร์ฟเวอร์กำลังสั่งให้ไคลเอนต์เรียกที่อยู่ใหม่ การตรวจสอบปลายทางแต่ละแห่งต่อเนื่องกันช่วยให้พบวงวนการเปลี่ยนเส้นทาง หรือการสลับระหว่าง HTTP กับ HTTPS ที่ไม่คาดคิดได้

หากหน้าเว็บหลัง Cloudflare หรือ CDN อื่นแสดงเนื้อหาเก่า ให้ตรวจสอบ Cache-Control, Age, ETag และส่วนหัวแคชเฉพาะของผู้ให้บริการ ค่าสูงใน Age หมายถึงอายุที่คำนวณได้ของการตอบกลับในแคช ซึ่งอาจรวมเวลาที่อยู่ในแคชต้นทาง ไม่ได้หมายถึงระยะเวลาที่ตัวกลางรายใดรายหนึ่งเก็บการตอบกลับนั้นไว้ และไม่ได้ยืนยันว่าแคชในทุกภูมิภาคมีเนื้อหาเวอร์ชันเดียวกัน

เมื่อ API ทำงานในสคริปต์ฝั่งเซิร์ฟเวอร์แต่ใช้ในเบราว์เซอร์ไม่ได้ ให้ตรวจสอบ Content-Type และส่วนหัวการตอบกลับ CORS รวมถึง Access-Control-Allow-Origin ปลายทาง JSON ที่ส่ง text/html กลับมาอาจกำลังแสดงหน้าข้อผิดพลาดหรือหน้าเข้าสู่ระบบ หากไม่มีสิทธิ์ข้ามต้นทาง เบราว์เซอร์อาจบล็อกการเข้าถึงแม้เซิร์ฟเวอร์จะส่งสถานะ 200 ก็ตาม

ส่วนหัวยังช่วยตรวจสอบเว็บไซต์ที่ดูเหมือนเข้าใช้งานไม่ได้ การตอบกลับ 503 ชี้ไปที่ความขัดข้องชั่วคราวของเซิร์ฟเวอร์หรือระบบต้นทาง ส่วน 404 หมายถึงไม่พบพาธที่ร้องขอ อย่างไรก็ตาม ส่วนหัววิเคราะห์ความขัดข้องไม่ได้ทุกกรณี หากการแปลงชื่อ DNS การเชื่อมต่อ TCP หรือการเจรจา TLS ล้มเหลวก่อนเกิดการตอบกลับ HTTP ก็อาจไม่มีส่วนหัวการตอบกลับให้ตรวจสอบ ใช้ปิงเพื่อตรวจสอบการเชื่อมต่อแยกต่างหาก และใช้ตัวตรวจสอบ HTTP/2 เพื่อตรวจสอบการรองรับโปรโตคอลได้

ทำไมผลส่วนหัวที่ถูกต้องจึงยังดูเหมือนผิด?

ผลลัพธ์ที่ถูกต้องอาจไม่ตรงกับเบราว์เซอร์ เพราะแคช ระเบียน DNS และบริบทของคำขออาจนำคำขอทั้งสองไปยังการตอบกลับคนละแบบ เครื่องมือนี้ทำงานบนเซิร์ฟเวอร์ จึงอาจเชื่อมต่อกับโหนด CDN คนละแห่ง หรือรับการเปลี่ยนแปลงล่าสุดของระเบียน DNS เร็วหรือช้ากว่าเครือข่ายในพื้นที่ของคุณ

เบราว์เซอร์ยังส่งคุกกี้ ประเภทเนื้อหาที่ยอมรับ ภาษา และตัวตรวจสอบแคชของตัวเองไปด้วย ดังนั้นหน้า WordPress ที่เข้าสู่ระบบแล้วอาจส่งกฎแคชต่างจากคำขอแบบไม่ระบุตัวตนจากเซิร์ฟเวอร์ ระบบกำหนดเส้นทางตามภูมิศาสตร์และระบบจัดการบอตอาจปรับการตอบกลับตามเครือข่ายต้นทางหรือส่วนหัวคำขอได้เช่นกัน

หลังเปลี่ยน DNS ตัวแปลงชื่อที่มีแคชอาจยังใช้ระเบียนเดิมจนกว่าค่า time to live จะหมดอายุ เมื่อการรับส่งข้อมูลไปถึงเซิร์ฟเวอร์ใหม่แล้ว ออบเจ็กต์เก่าใน CDN หรือแคชของเบราว์เซอร์ก็อาจยังส่งเนื้อหาเดิมกลับมา ตรวจสอบโฮสต์ที่แปลงชื่อได้แยกต่างหาก ล้างแคชตามความเหมาะสม และเปรียบเทียบ URL แบบตรงตัว แทนที่จะคิดว่าโฮสต์เนมทุกชื่อใช้การกำหนดค่าเดียวกัน

คำถามที่พบบ่อย

เครื่องมือนี้แสดงส่วนหัวคำขอด้วยไหม?

ไม่ เครื่องมือนี้ดึงเฉพาะส่วนหัวการตอบกลับที่ URL ส่งกลับมาสำหรับคำขอ GET ทั่วไป ส่วนหัวคำขอคือข้อมูลเมตาที่ส่งไปยังเซิร์ฟเวอร์ หากต้องการตรวจสอบอย่างครบถ้วน ต้องใช้เครื่องมือนักพัฒนาของเบราว์เซอร์ บันทึกของเซิร์ฟเวอร์ หรือไคลเอนต์บรรทัดคำสั่งแยกต่างหาก

URL ที่ป้อนในเครื่องมือเป็นข้อมูลส่วนตัวไหม?

การค้นหาดำเนินการบนเซิร์ฟเวอร์ ข้อมูลที่ป้อนจะถูกส่งไปยังเซิร์ฟเวอร์นั้นผ่าน HTTPS และไม่มีการจัดเก็บไว้ หลีกเลี่ยงการป้อน URL ที่มีรหัสผ่าน โทเค็นการเข้าถึง หรือพารามิเตอร์คิวรีที่ละเอียดอ่อน เพราะเซิร์ฟเวอร์ปลายทางจะได้รับค่าเหล่านั้นด้วยเมื่อมีการส่งคำขอ

ส่วนหัว HTTP บอกสาเหตุของคำเตือนใบรับรองได้ไหม?

โดยทั่วไป ส่วนหัวเพียงอย่างเดียวบอกไม่ได้ การเชื่อมต่อ TLS เกิดขึ้นก่อนส่งการตอบกลับ HTTP ดังนั้นใบรับรองที่หมดอายุ ชื่อโฮสต์ไม่ตรงกัน หรือผู้ออกใบรับรองที่ไม่ได้รับความเชื่อถือ อาจทำให้ไม่มีส่วนหัวใดถูกส่งกลับมา หากเบราว์เซอร์แสดงคำเตือนก่อนหน้าเว็บโหลด ให้ตรวจสอบใบรับรองและสายโซ่ใบรับรองแยกต่างหาก

ทำไมจึงมีส่วนหัว Set-Cookie หลายรายการ?

การตอบกลับหนึ่งครั้งอาจกำหนดคุกกี้ได้มากกว่าหนึ่งรายการ และคุกกี้แต่ละรายการจะใช้ฟิลด์ Set-Cookie ของตัวเอง อย่านำมารวมกันเสมือนเป็นรายการที่คั่นด้วยจุลภาค เพราะวันที่หมดอายุของคุกกี้เองก็อาจมีจุลภาคได้ ควรตรวจสอบโดเมน พาธ และแอตทริบิวต์ด้านความปลอดภัยของคุกกี้แต่ละรายการแยกกัน

เปรียบเทียบผลลัพธ์กับ curl ได้ไหม?

ได้ คำสั่งอย่าง curl -D - https://example.com/ -o /dev/null จะแสดงส่วนหัวการตอบกลับและทิ้งเนื้อหาการตอบกลับ เวอร์ชันของ Curl ส่วนหัวคำขอ การตั้งค่าการเปลี่ยนเส้นทาง และตำแหน่งเครือข่ายอาจทำให้ได้ผลต่างกัน ดังนั้นควรทำให้เงื่อนไขเหล่านี้ตรงกันก่อนสรุปว่าความแตกต่างเกิดจากข้อผิดพลาดของเซิร์ฟเวอร์

แชร์

เครื่องมือยอดนิยม