การรองรับส่วนหัวการตอบกลับ HTTP

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X ข้อมูล

หัวข้อนี้จะอธิบายวิธีที่ Edge จัดการส่วนหัวการแคช HTTP/1.1 เมื่อใช้นโยบาย ResponseCache ปัจจุบัน Apigee Edge รองรับส่วนหัวและคำสั่งการแคช HTTP/1.1 บางส่วน (มีการระบุฟีเจอร์ที่ไม่รองรับในหัวข้อนี้) ที่ได้รับจากเซิร์ฟเวอร์เป้าหมาย (ต้นทาง) แบ็กเอนด์

นอกจากนี้ ส่วนหัวบางรายการ Edge จะดำเนินการตามคำแนะนำของส่วนหัวดังกล่าว ในบางกรณี ส่วนหัวของแคช HTTP/1.1 เหล่านี้จะลบล้างลักษณะการทำงานที่ระบุไว้ในนโยบาย ResponseCache เช่น หากส่งส่วนหัว Cache-Control มาจากเซิร์ฟเวอร์แบ็กเอนด์ คุณจะกำหนดให้คำสั่ง s-maxage ของส่วนหัวอาจลบล้างการตั้งค่าวันหมดอายุอื่นๆ ในนโยบายได้

ส่วนหัว	การสนับสนุน
การควบคุมแคช	รองรับการตอบกลับจากเซิร์ฟเวอร์ต้นทางแบ็กเอนด์ แต่ไม่รองรับคำขอของไคลเอ็นต์ Edge รองรับคำสั่งบางส่วน
หมดอายุ	รองรับ ลบล้างได้
แท็กเอนทิตี (ETag)	ลักษณะการทำงานที่เจาะจงสำหรับ If-Match และ If-None-Match
If-Modified-From	ในคำขอ GET ระบบจะส่งส่วนหัวไปยังเซิร์ฟเวอร์ต้นทางแม้ว่าจะมีรายการแคชที่ถูกต้องก็ตาม
ยอมรับการเข้ารหัส	Edge จะส่งการตอบกลับที่บีบอัดหรือไม่บีบอัดโดยขึ้นอยู่กับส่วนหัวขาเข้า

Cache-Control

Apigee Edge รองรับส่วนหัว Cache-Control เท่านั้นในการตอบสนองที่แสดงผลจากเซิร์ฟเวอร์ต้นทางของแบ็กเอนด์ (ข้อกำหนด HTTP/1.1 อนุญาตให้ใช้ส่วนหัว Cache-Control ทั้งในคำขอของไคลเอ็นต์และการตอบกลับของเซิร์ฟเวอร์ต้นทาง) เซิร์ฟเวอร์ต้นทางจะมีทั้งปลายทางเป้าหมายที่กำหนดไว้ในพร็อกซี Apigee Edge API และปลายทางที่สร้างขึ้นโดยใช้การเรียก TargetServer API

ข้อจำกัดการรองรับการควบคุมแคช

Apigee Edge รองรับความสามารถบางส่วนของส่วนหัวการตอบกลับ Cache-Control ที่กำหนดไว้ในข้อกำหนด HTTP/1.1 โปรดทราบข้อมูลต่อไปนี้

• Apigee Edge ไม่รองรับส่วนหัว Cache-Control ที่มาถึงพร้อมคำขอของไคลเอ็นต์ขาเข้า
• Apigee Edge เท่านั้นที่สนับสนุนเฉพาะแนวคิดเกี่ยวกับแคชสาธารณะ (ตามข้อกำหนดของ HTTP ระบุไว้ว่า Cache-Control เป็นแบบสาธารณะ (แชร์) หรือส่วนตัว (ผู้ใช้รายเดียว) ก็ได้)
• Apigee Edge รองรับเฉพาะคำสั่งการตอบสนอง Cache-Control บางส่วนในข้อกำหนด HTTP/1.1 ดูรายละเอียดได้ที่การรองรับคำสั่งส่วนหัวการตอบสนองการควบคุมแคช

การรองรับคำสั่งส่วนหัวการตอบสนองของการควบคุมแคช

Apigee รองรับคำสั่งย่อยจากข้อกำหนด HTTP/1.1 เกี่ยวกับการตอบกลับจากเซิร์ฟเวอร์ต้นทาง ตารางต่อไปนี้อธิบายการรองรับ Apigee Edge สำหรับคำสั่งส่วนหัวการตอบกลับการควบคุมแคช HTTP

โปรดดูรายละเอียดเพิ่มเติมเกี่ยวกับคำสั่งที่แสดงอยู่ที่นี่ Cache-Control ในข้อมูลจำเพาะของ HTTP/1.1

คำสั่งการควบคุมแคช	วิธีที่ Apigee Edge ประมวลผลคำสั่ง
cache-extension	ไม่รองรับ
max-age	หากนโยบาย ResponseCache กำหนดเอลิเมนต์ <UseResponseCacheHeaders> เป็น true ระบบจะแคชการตอบสนองได้ตามจำนวนวินาทีที่ระบุโดยคำสั่งนี้ คำสั่ง s-maxage ถูกลบล้างคำสั่งนี้และลบล้างส่วนหัว Expires หรืออาจลบล้างโดยองค์ประกอบ <ExpirySettings> ของนโยบายก็ได้ ดูข้อมูลเพิ่มเติมได้ที่ "การตั้งค่าวันหมดอายุของรายการแคช" และ <UseResponseCacheHeaders> ในนโยบายแคชการตอบกลับ
must-revalidate	ไม่รองรับ Apigee Edge จะลบข้อมูลแคชทั้งหมดทันทีที่หมดอายุ
no-cache	Edge จะแคชการตอบกลับต้นทาง แต่ต้องมีการตรวจสอบอีกครั้งด้วยเซิร์ฟเวอร์ต้นทางก่อนนำไปใช้เพื่อตอบสนองคำขอของไคลเอ็นต์ที่ตามมา กฎนี้อนุญาตให้ต้นทางแสดงผลการตอบกลับ 304 Not Modified เพื่อระบุว่าควรส่งคืนการตอบกลับจากแคช ซึ่งจะบันทึกการประมวลผลที่จำเป็นต่อการแสดงผลการตอบกลับทั้งหมด หากเซิร์ฟเวอร์ต้นทางส่งการตอบกลับแบบเต็ม เซิร์ฟเวอร์ดังกล่าวจะแทนที่รายการแคชที่มีอยู่ ระบบจะไม่สนใจชื่อช่องที่ระบุด้วยคำสั่งนี้
no-store	ไม่รองรับ
no-transform	ไม่รองรับ
private	ไม่รองรับ หากได้รับคำสั่งนี้ การตอบสนองของต้นทางจะไม่มีการแคช ระบบจะไม่สนใจชื่อช่องใดๆ
proxy-revalidate	ไม่รองรับ Apigee Edge จะลบข้อมูลแคชทั้งหมดทันทีที่หมดอายุ
public	Edge จะแคชการตอบสนองต้นทาง แม้ว่าคำสั่งอื่นๆ จะระบุไว้เป็นอย่างอื่น ตามข้อกำหนดของ HTTP/1.1 ข้อยกเว้นเพียงอย่างเดียวของกฎนี้คือกรณีที่การตอบกลับมีส่วนหัวการให้สิทธิ์
s-maxage	หากนโยบาย ResponseCache กำหนดเอลิเมนต์ <UseResponseCacheHeaders> เป็น true ระบบจะแคชการตอบสนองได้ตามจำนวนวินาทีที่ระบุโดยคำสั่งนี้ คำสั่งนี้จะลบล้างคำสั่ง max-age และส่วนหัว Expires ลบล้างได้โดยองค์ประกอบ <ExpirySettings> ของนโยบาย ดูข้อมูลเพิ่มเติมได้ที่ "การตั้งค่าวันหมดอายุของรายการแคช" และ <UseResponseCacheHeaders> ในนโยบายแคชการตอบกลับ

หมดอายุ

เมื่อตั้งค่าสถานะ UseResponseCacheHeaders ในนโยบาย ResponseCache เป็น true Edge จะใช้ส่วนหัว Expires เพื่อระบุ Time to Live (TTL) ของรายการที่แคชไว้ได้ ส่วนหัวนี้จะระบุวันที่/เวลาซึ่งระบบพิจารณาว่ารายการแคชของการตอบกลับไม่มีการอัปเดต ส่วนหัวนี้ช่วยให้เซิร์ฟเวอร์ส่งสัญญาณได้ว่าจะแสดงค่าที่แคชไว้โดยอิงตามการประทับเวลาได้

รูปแบบวันที่ที่ยอมรับสำหรับส่วนหัว Expires มีอธิบายอยู่ในข้อมูลจำเพาะของ HTTP/1.1 เช่น

หมดอายุ: วันพฤหัสที่ 1 ธันวาคม 1994 เวลา 16:00:00 น. GMT

สำหรับข้อมูลโดยละเอียดเกี่ยวกับรูปแบบวันที่/เวลา HTTP โปรดดูรูปแบบวันที่/เวลาในข้อมูลจำเพาะของ HTTP/1.1

ดูข้อมูลเพิ่มเติมเกี่ยวกับส่วนหัว Expires ได้ที่คำจำกัดความช่องส่วนหัวในข้อมูลจำเพาะของ HTTP/1.1

ETag

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

เมื่อปลายทางเป้าหมายส่งการตอบกลับกลับไปยัง Edge ด้วย ETag แล้ว Edge จะแคช ETag พร้อมกับการตอบกลับดังกล่าว

อ่านข้อมูลเพิ่มเติมเกี่ยวกับแท็กเอนทิตีได้ในพารามิเตอร์โปรโตคอลในข้อกำหนด HTTP/1.1

หากตรงกัน

เมื่อใช้ส่วนหัวของคำขอ If-Match เอนทิตีที่แคชไว้จะเป็นปัจจุบันหาก ETag ในส่วนหัวตรงกับ ETag ที่แคชไว้ ระบบจะส่งคำขออื่นๆ นอกเหนือจาก GET ที่ระบุส่วนหัว If-Match ไปยังเซิร์ฟเวอร์ต้นทางเพื่อให้มั่นใจว่าระบบการแคชต้นทางจะมีโอกาสดำเนินการตามคำขอได้

อ่านข้อมูลเพิ่มเติมเกี่ยวกับ If-Match ได้ในคำจำกัดความช่องส่วนหัวในข้อกำหนด HTTP/1.1

หาก Edge ได้รับคำขอ GET ขาเข้าจากไคลเอ็นต์ที่มีส่วนหัว If-Match ให้ทำดังนี้

หาก	จากนั้น
ส่วนหัว If-Match ระบุ ETag อย่างน้อย 1 รายการ	Apigee Edge จะดึงข้อมูลรายการแคชที่ยังไม่หมดอายุสำหรับทรัพยากรที่ระบุ และเปรียบเทียบ ETag ที่มีประสิทธิภาพในรายการที่แคชกับรายการแคชที่ระบุไว้ในส่วนหัว If-Match หากพบรายการที่ตรงกัน ระบบจะแสดงรายการแคช ไม่เช่นนั้น ระบบจะส่งคําขอไปยังเซิร์ฟเวอร์ต้นทาง
ส่วนหัว If-Match ระบุ "*"	ระบบจะส่งต่อคำขอไปยังเซิร์ฟเวอร์ต้นทางเพื่อให้มั่นใจว่าพื้นที่การแคชต้นทางจะมีโอกาสประมวลผลคำขอ
พบรายการแคชที่มี URI คำขอเดียวกัน แต่มีเฉพาะ ETag ที่ไม่รัดกุม	เซิร์ฟเวอร์ต้นทางต้องตรวจสอบรายการอีกครั้งก่อนจึงจะส่งคืนไปยังไคลเอ็นต์ได้
ETag มาจากเซิร์ฟเวอร์ต้นทาง	ส่ง ETag โดยไม่เปลี่ยนแปลงไปยังไคลเอ็นต์

หากไม่มี-ตรงกัน

เมื่อใช้ส่วนหัว If-None-Match เอนทิตีที่แคชไว้จะเป็นปัจจุบันหาก ETag ในส่วนหัวไม่ตรงกันกับ ETag ที่แคชไว้ ระบบจะส่งคำขอที่ไม่ใช่ GET ที่มีส่วนหัวนี้ไปยังเซิร์ฟเวอร์ต้นทาง

หาก Edge ได้รับคำขอ GET ขาเข้าที่มีส่วนหัวนี้

หาก	จากนั้น
ส่วนหัว If-None-Match ระบุ ETag อย่างน้อย 1 รายการ	Apigee Edge จะดึงข้อมูลรายการแคชที่ยังไม่หมดอายุสำหรับ URI ที่ระบุและเปรียบเทียบ ETag ที่มีประสิทธิภาพในรายการที่แคชเหล่านั้นกับรายการแคชที่ระบุในส่วนหัว If-None-Match หากพบรายการที่ตรงกัน Edge จะแสดงสถานะ 304 Not Modified ปรากฏขึ้น หากไม่พบรายการที่ตรงกัน Edge จะส่งคำขอไปยังเซิร์ฟเวอร์ต้นทาง
ส่วนหัว If-None-Match ระบุ "*" และมีรายการที่แคชไว้ที่ยังไม่หมดอายุสำหรับ URI ที่ขอ	Edge ส่งคืนสถานะ 304 Not Modified
พบรายการแคชที่มี URI คำขอเดียวกัน แต่มีเพียง ETag ที่ไม่รัดกุม	เซิร์ฟเวอร์ต้นทางต้องตรวจสอบรายการอีกครั้งก่อนที่ Edge จะส่งรายการกลับไปยังไคลเอ็นต์
Edge ได้รับ ETag จากเซิร์ฟเวอร์ต้นทาง	ส่ง ETag โดยไม่เปลี่ยนแปลงไปยังไคลเอ็นต์

หากแก้ไข-ตั้งแต่

หาก Apigee Edge ได้รับส่วนหัว If-Modified-Since ในคำขอ GET ระบบจะส่งต่อไปยังเซิร์ฟเวอร์ต้นทางแม้ว่าจะมีรายการแคชที่ถูกต้องก็ตาม

การดำเนินการนี้จะทำให้การอัปเดตทรัพยากรที่ไม่ผ่าน Apigee Edge ได้รับการพิจารณา หากเซิร์ฟเวอร์ต้นทางส่งเอนทิตีใหม่กลับมา Edge จะแทนที่รายการแคชที่มีอยู่ด้วยค่าใหม่ หากเซิร์ฟเวอร์ส่งสถานะ 304 Not Modified กลับมา Edge จะแสดงค่าการตอบกลับหากส่วนหัว Last-Modified ของการตอบกลับที่แคชระบุว่าไม่มีการเปลี่ยนแปลง

ยอมรับการเข้ารหัส

เมื่อคำขอขาเข้ามีส่วนหัว Accept-Encoding ที่มีค่าเป็น gzip, deflate หรือ compress เซิร์ฟเวอร์ต้นทางจะตอบสนองด้วยข้อมูลที่บีบอัด เมื่อคําขอที่ตามมาไม่มีส่วนหัว Accept-Encoding ก็จะได้รับการตอบกลับที่ไม่ได้บีบอัด กลไกการแคชการตอบกลับของ Apigee ส่งได้ทั้งการตอบกลับที่บีบอัดและไม่ได้บีบอัด ทั้งนี้ขึ้นอยู่กับส่วนหัวขาเข้าโดยไม่ต้องกลับไปยังเซิร์ฟเวอร์ต้นทาง

คุณเพิ่มค่าส่วนหัวยอมรับต่อท้ายคีย์แคชได้เพื่อให้คีย์มีความหมายมากขึ้นสำหรับรายการที่แคชไว้แต่ละรายการ โปรดดูรายละเอียดเพิ่มเติมที่ "การกำหนดค่าคีย์แคช" ในนโยบายแคชการตอบกลับ