เนื่องจากค่าเน็ตมือถือในไทยยังเป็นภาระสำหรับผู้ใช้จำนวนมาก แอปเบราว์เซอร์ประหยัดดาต้าและพร็อกซีบางส่วนของผู้ให้บริการเครือข่ายจึงบีบอัดข้อมูลระหว่างทางก่อนถึงอุปกรณ์ พร็อกซีเหล่านี้มักเพิ่มเฮดเดอร์ Via เพื่อระบุเซิร์ฟเวอร์ตัวกลางที่คำขอผ่านมา และบางครั้งก็เปลี่ยน Content-Encoding หรือคุณภาพของรูปภาพไปด้วย — ทำให้นักพัฒนาอาจเข้าใจผิดว่าเซิร์ฟเวอร์ของตัวเองส่ง response ผิดพลาด ทั้งที่ปัญหาจริงอยู่ที่เครือข่ายตัวกลาง
Request Headers กับ Response Headers
เบราว์เซอร์ส่ง request headers (เช่น Accept, User-Agent, Cookie) ไปยังเซิร์ฟเวอร์ อธิบายตัวมันเองและสิ่งที่คาดหวัง เซิร์ฟเวอร์ตอบกลับด้วย response headers (Content-Type, Set-Cookie, Cache-Control) อธิบายข้อมูลที่ส่งกลับและคำสั่งสำหรับเบราว์เซอร์
เหตุใด Content-Type จึงจำเป็น
เฮดเดอร์ Content-Type บอกเบราว์เซอร์ว่าจะตีความ body ของการตอบกลับอย่างไร: เป็นหน้า HTML, ข้อมูล JSON, รูปภาพ หรือไฟล์ดาวน์โหลด หากไม่มีค่าที่ถูกต้องตรงนี้ เบราว์เซอร์อาจพยายามแสดง JSON เป็นข้อความธรรมดา หรือในทางกลับกัน ประมวลผล HTML อย่างผิดพลาด
Cache-Control ควบคุมการแคชอย่างไร
ค่าอย่าง max-age=3600 หรือ no-cache บอกเบราว์เซอร์และเซิร์ฟเวอร์ตัวกลางว่าสามารถใช้สำเนาแคชของรีซอร์สได้นานแค่ไหนโดยไม่ต้องขอใหม่จากเซิร์ฟเวอร์ การตั้งค่าเฮดเดอร์นี้ผิดพลาดเป็นสาเหตุทั่วไปที่ผู้ใช้เห็นเว็บไซต์เวอร์ชันเก่า
เหตุใดจึงจำเป็น
- วินิจฉัยว่าเหตุใดเบราว์เซอร์จึงแสดงการตอบกลับของ API ผิดพลาด
- ตรวจจับเฮดเดอร์
Viaที่บ่งชี้ว่า response ผ่านพร็อกซีบีบอัดข้อมูลของผู้ให้บริการเครือข่ายมา - ยืนยันว่าเว็บไซต์ถูกส่งผ่าน HTTPS — เงื่อนไขบังคับให้ Web Crypto API ที่เครื่องมือแฮชและ JWT ของเว็บไซต์นี้เองต้องพึ่งพาทำงานได้
เหตุใดบางครั้งเฮดเดอร์เดียวจึงปรากฏหลายครั้ง
HTTP อนุญาตให้เฮดเดอร์เดียวกันปรากฏหลายครั้งในการตอบกลับเดียว — กรณีที่พบบ่อยที่สุดคือหลายบรรทัดของ Set-Cookie หนึ่งบรรทัดต่อหนึ่งคุกกี้ที่ตั้งค่า เฮดเดอร์ที่ซ้ำกันส่วนใหญ่สามารถรวมเป็นค่าเดียวคั่นด้วยจุลภาคได้โดยไม่เปลี่ยนความหมาย แต่ Set-Cookie เป็นข้อยกเว้นที่ตั้งใจไว้ เนื่องจากจุลภาคอาจเป็นส่วนหนึ่งของค่าคุกกี้ได้อย่างถูกต้อง