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

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

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

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

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

Cache-Control

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

ข้อจำกัดในการรองรับ Cache-Control

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

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

การรองรับคำสั่งส่วนหัวการตอบกลับ Cache-Control

Apigee รองรับคำสั่งเพียงบางส่วนจากข้อกำหนดเฉพาะของ HTTP/1.1 ในการตอบกลับจากเซิร์ฟเวอร์ต้นทาง ตารางต่อไปนี้อธิบายการรองรับคำสั่งส่วนหัวการตอบกลับ Cache-Control ของ HTTP ใน Apigee Edge

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

คำสั่ง Cache-Control วิธีที่ 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 ข้อกำหนดนี้มีข้อยกเว้นเพียงกรณีเดียวคือหากการตอบกลับมีส่วนหัว Authorization
s-maxage

หากนโยบาย ResponseCache ตั้งค่าองค์ประกอบ <UseResponseCacheHeaders> เป็น true ระบบจะแคชการตอบกลับเป็นจำนวนวินาที ที่ระบุโดยคำสั่งนี้

คำสั่งนี้จะลบล้างคำสั่ง max-age และส่วนหัว Expires นอกจากนี้ยังสามารถลบล้างได้ด้วยองค์ประกอบ <ExpirySettings> ของนโยบาย ดูข้อมูลเพิ่มเติมได้ที่ "การตั้งค่าการหมดอายุของรายการแคช" และ <UseResponseCacheHeaders> ใน นโยบายแคชการตอบกลับ

Expires

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

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

Expires: Thu, 01 Dec 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

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

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

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

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

If-None-Match

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

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

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

ส่วนหัว If-None-Match ระบุ "*" และมีรายการที่แคชไว้ซึ่งยังไม่หมดอายุสำหรับ URI ที่ขอ

 Edge จะแสดงสถานะ 304 Not Modified
พบรายการแคชที่มี URI คำขอเดียวกัน แต่มีเพียง ETag ที่ไม่เข้มงวด เซิร์ฟเวอร์ต้นทางต้องตรวจสอบรายการอีกครั้งก่อนที่ Edge จะแสดงรายการให้ ไคลเอ็นต์
Edge ได้รับ ETag จากเซิร์ฟเวอร์ต้นทาง ระบบจะแสดง ETag ให้ไคลเอ็นต์โดยไม่มีการเปลี่ยนแปลง

If-Modified-Since

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

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

Accept-Encoding

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

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