คุณสมบัติที่ซ่อนอยู่ของ HTTP

คุณลักษณะที่ซ่อนอยู่ของ HTTP ใดที่คุณคิดว่าควรค่าแก่การกล่าวถึง

โดยคุณสมบัติที่ซ่อนอยู่ฉันหมายถึงคุณลักษณะที่เป็นส่วนหนึ่งของมาตรฐานอยู่แล้ว แต่ค่อนข้างไม่เป็นที่รู้จักหรือไม่ได้ใช้

โปรดเพียงหนึ่งคุณสมบัติต่อคำตอบ

ต้องเป็นรหัสสถานะ418 I'm a teapotซึ่งเป็นส่วนหนึ่งของHyper Text Coffee Pot Control Protocol (ส่วนขยายของ HTTP) ทำให้ฉันหัวเราะทุกครั้ง

2.3.2 418 ฉันเป็นกาน้ำชา

ความพยายามในการชงกาแฟด้วยกาน้ำชาควรทำให้เกิดรหัสข้อผิดพลาด "418 ฉันคือกาน้ำชา" ร่างกายของเอนทิตีที่ได้อาจสั้นและอ้วน

ข้อเท็จจริงที่ว่าผู้อ้างอิงถูกสะกดผิดและมีการตัดสินใจว่าควรเก็บการสะกดผิดไว้

คำตอบที่ชัดเจน: PUT, DELETE, TRACE, OPTIONS, CONNECT method

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

ใครเคยเห็น402 Payment Requiredหรือไม่?

204 ไม่มีเนื้อหา

ฉันคิดว่า 204 เป็นเพียงถ้าคุณไม่มีเนื้อหาที่จะแสดง แต่ข้อมูลจำเพาะดูเหมือนว่ามีพฤติกรรมเพิ่มเติมที่ตัวแทนผู้ใช้ "ไม่เปลี่ยนมุมมองเอกสาร"

ตามHOWTO: กำหนดค่า Apache เพื่อส่งคืน HTTP 204 (ไม่มีเนื้อหา) สำหรับ AJAX

FWIW Google ทำสิ่งที่คล้ายกัน ทุกครั้งที่ผู้ใช้คลิกลิงก์ในผลการค้นหา Google จะส่งคำสั่งเพื่อบันทึกการคลิกนั้น รหัสตอบกลับจาก ping คือ HTTP 204

นอกจากนี้204 No Content ยังเสนอว่านี่เป็นเทคนิคที่ดีสำหรับ "เว็บบั๊ก" หรือ "บีคอน" หากคุณต้องการประหยัดปริมาณการใช้งานเครือข่ายทุกๆไบต์สุดท้ายที่คุณสามารถทำได้

รหัสตอบกลับ410 Gone :

(... ) เจ้าของเซิร์ฟเวอร์ต้องการให้ลบลิงก์ระยะไกลไปยังทรัพยากรนั้น (... )

เว็บสไปเดอร์ (โดยเฉพาะอย่างยิ่งคือ Google) จะยกเลิกการจัดทำดัชนี (โดยทั่วไปในการรวบรวมข้อมูลครั้งถัดไป) ซึ่งเริ่มส่งคืน 410

ในเนื้อหาไดนามิกให้ใช้ Last_Modified หรือส่วนหัว ETag

ในบางครั้งคุณมีเนื้อหาแบบไดนามิกที่อาจมีขนาดใหญ่และ / หรือมีค่าใช้จ่ายสูงในการสร้างและอาจไม่เปลี่ยนแปลงจากคำขอเป็นคำขอ คุณสามารถเพิ่มส่วนหัว Last_Modified หรือ ETag ในการตอบกลับที่คุณสร้างขึ้น

ที่ด้านบนของโค้ดไดนามิกราคาแพงของคุณคุณสามารถใช้ If_Modified_Since หรือ If_None_Match เพื่อตรวจสอบว่าผู้ร้องขอเนื้อหายังคงเป็นปัจจุบันอยู่หรือไม่ หากมีการเปลี่ยนสถานะการตอบกลับเป็น "304 Unmodified" และสิ้นสุดคำขอ

เทคโนโลยีฝั่งเซิร์ฟเวอร์บางอย่างมีคุณสมบัติดังกล่าวอย่างเป็นทางการ แต่คุณสามารถทำได้ข้างต้นแม้ใน ASP-Classic ที่ต่ำ

โปรดทราบว่าสิ่งนี้แตกต่างจากการตั้งค่า Cache-Control, Expires headers ตรงที่ทำให้แน่ใจว่าไคลเอนต์มีข้อมูลล่าสุดตามคำขอ

คุณสามารถขอดำเนินการตอบกลับ HTTP (ขนาดใหญ่) ต่อ (เช่นการดาวน์โหลดไฟล์) โดยใช้RangeและIf-Rangeขอส่วนหัวตามลำดับช่วงไบต์ที่ระบุและตัวระบุไฟล์ที่ไม่ซ้ำกันหรือการประทับเวลาการแก้ไขไฟล์ สิ่งนี้เป็นไปได้ถ้าเซิร์ฟเวอร์ส่งAccept-Ranges: bytesและETagหรือLast-Modifiedส่วนหัวการตอบกลับในการตอบกลับครั้งแรกพร้อมกับการแจ้งเตือนตามลำดับว่าเซิร์ฟเวอร์รองรับคำขอช่วงไบต์ตัวระบุไฟล์ที่ไม่ซ้ำกันและการประทับเวลาการแก้ไขไฟล์

การตอบสนองเริ่มต้นอาจมีลักษณะดังนี้ ( ETagโดยปกติจะประกอบด้วยชื่อไฟล์ขนาดและการประทับเวลาแก้ไขล่าสุด):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

เมื่อการดาวน์โหลดถูกยกเลิกเช่น 1KB (1024 ไบต์) ไคลเอ็นต์สามารถดำเนินการต่อได้ดังนี้:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

ซึ่งควรส่งคืนการตอบสนองนี้ด้วยไบต์ที่เหมาะสมในร่างกาย:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

ReSTพยายามดัน HTTP จนถึงขีด จำกัด เป็นโปรโตคอลอินเทอร์เฟซ

ไม่ใช่คุณลักษณะที่ซ่อนอยู่แต่จากการดู ReST API ที่กำหนดไว้อย่างดีเราจะได้รับความเข้าใจที่ดีเกี่ยวกับวิธีการทำงานของ HTTP และค้นหาตัวอย่างที่ยอดเยี่ยมของสิ่งที่สามารถทำได้ด้วยการรวมกันอย่างง่ายของวิธี HTTP รหัสสถานะและส่วนหัว เทียว

ตัวอย่าง (ตรงกันข้ามกับ Header)

โปรโตคอลช่วยให้คุณกำหนดฟิลด์ที่คุณกำหนดเองได้ สิ่งเหล่านี้สามารถใช้เพื่อส่งข้อมูลอื่น ๆ ได้หากคุณไม่ต้องการใช้คุกกี้

สถานะ HTTP 100 (ดำเนินการต่อ)

ไคลเอนต์สามารถส่งข้อความร้องขอพร้อมกับเนื้อหาของคำร้องขอเพื่อตรวจสอบว่าเซิร์ฟเวอร์ต้นทางยินดีที่จะยอมรับคำขอหรือไม่ ..

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

สามารถใช้เพื่อหลีกเลี่ยงการรับส่งข้อมูลจากลูกค้าที่โกง .. และ / หรือแบนด์วิดท์เป็นสินค้าที่มีค่า

อย่างไรก็ตามสำหรับการใช้คุณลักษณะนี้อย่างเต็มรูปแบบมีเกณฑ์บางประการสำหรับไคลเอ็นต์ HTTP1.1 เซิร์ฟเวอร์และพร็อกซี โปรดดูHTTP / 1.1 RFC 2616สำหรับการอ่านเพิ่มเติมเกี่ยวกับ HTTP Connections

รหัสสถานะ :

• เมื่อURI http://www.domain.invalid/index.php?id=44เรียกว่าถ้าแบบสอบถาม ( id=44) ไม่สามารถกลับ Ressource ทำไมไม่ส่งคืนรหัสสถานะ404?
• เมื่อURI http://www.domain.invalid/index.php?id=fooที่เรียกว่าในขณะที่idยอมรับเฉพาะจำนวนเต็มทำไมไม่ส่งคืนรหัสสถานะ400?
• ทำไมเมื่อคุณป้อนข้อมูลเข้าสู่ระบบ / รหัสผ่านไม่ถูกต้องเว็บแอปพลิเคชันเกือบทั้งหมดจะแสดงข้อความว่า"การตรวจสอบความถูกต้องล้มเหลว"พร้อมรหัสสถานะ200(โอเคไม่มีปัญหาคุณทำได้ดี) ติดตั้ง401?

ใช่รหัสสถานะดูเหมือนจะเป็นฟังก์ชันลับของHTTPสำหรับนักพัฒนาเว็บบางราย ... แต่ฉันสงสัยว่า "คุณสมบัติ" ทั้งหมดที่ลึกลับที่สุดของโปรโตคอลนี้ไม่ใช่RFC !