คุณกําลังดูเอกสารประกอบของ 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 รองรับคำสั่งเพียงบางส่วน |
หมดอายุ | รองรับ ลบล้างได้ |
แท็กเอนทิตี (ETag) | ลักษณะการทํางานเฉพาะสําหรับ If-Match และ If-None-Match |
If-Modified-Since | ในคำขอ GET ระบบจะส่งส่วนหัวไปยังเซิร์ฟเวอร์ต้นทางแม้ว่าจะมีรายการแคชที่ถูกต้องอยู่ก็ตาม |
Accept-Encoding | Edge จะส่งคำตอบแบบบีบอัดหรือไม่บีบอัดโดยขึ้นอยู่กับส่วนหัวขาเข้า |
Cache-Control
Apigee Edge รองรับส่วนหัว Cache-Control
เฉพาะในการตอบกลับที่ส่งกลับจากเซิร์ฟเวอร์ต้นทางแบ็กเอนด์ (ข้อกำหนด HTTP/1.1 อนุญาตให้ใช้ส่วนหัว Cache-Control
ทั้งในคำขอไคลเอ็นต์และการตอบกลับของเซิร์ฟเวอร์ต้นทาง) เซิร์ฟเวอร์ต้นทางอาจมีทั้งปลายทางเป้าหมายที่กําหนดไว้ในพร็อกซี Apigee Edge API และปลายทางที่สร้างขึ้นโดยใช้การเรียก 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 เกี่ยวกับการตอบกลับจากเซิร์ฟเวอร์ต้นทาง ตารางต่อไปนี้อธิบายการรองรับของ Apigee Edge สําหรับคําสั่งส่วนหัวการตอบกลับ Cache-Control ของ HTTP
ดูรายละเอียดเพิ่มเติมเกี่ยวกับคําสั่งที่ระบุไว้ที่นี่ได้ในส่วน Cache-Control ในข้อกําหนดเฉพาะ HTTP/1.1
คำสั่ง Cache-Control | วิธีที่ Apigee Edge ประมวลผลคําสั่ง |
cache-extension |
ไม่รองรับ |
max-age |
หากนโยบาย ResponseCache ตั้งค่าองค์ประกอบ คำสั่งนี้ถูกลบล้างโดยคำสั่ง |
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 ตั้งค่าองค์ประกอบ คำสั่งนี้จะลบล้างคำสั่ง |
หมดอายุ
เมื่อตั้งค่า Flag UseResponseCacheHeaders
ในนโยบาย ResponseCache เป็น true
แล้ว Edge จะใช้ส่วนหัว Expires
เพื่อกำหนด Time to Live (TTL) ของรายการที่แคชไว้ ส่วนหัวนี้ระบุวันที่/เวลาหลังจากที่รายการแคชของการตอบกลับจะถือว่าล้าสมัย ส่วนหัวนี้ช่วยให้เซิร์ฟเวอร์ส่งสัญญาณได้เมื่อส่งคืนค่าที่แคชไว้ได้ โดยอิงตามการประทับเวลา
รูปแบบวันที่ที่ยอมรับสำหรับส่วนหัว Expires
อธิบายไว้ในข้อกำหนดเฉพาะของ HTTP/1.1 เช่น
หมดอายุ: พฤหัสบดีที่ 01 ธ.ค. 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 รายการ |
|
ส่วนหัว If-Match ระบุ "*" |
ระบบจะส่งต่อคำขอไปยังเซิร์ฟเวอร์ต้นทางเพื่อให้แน่ใจว่าระบบแคชต้นทางมีโอกาสประมวลผลคำขอ |
พบรายการแคชที่มี URI คำขอเดียวกัน แต่มีเฉพาะ ETag ที่มีประสิทธิภาพต่ำ | เซิร์ฟเวอร์ต้นทางต้องตรวจสอบรายการอีกครั้งก่อนที่จะส่งกลับไปยังไคลเอ็นต์ |
ETag มาจากเซิร์ฟเวอร์ต้นทาง | ระบบจะแสดง ETag แก่ไคลเอ็นต์โดยไม่มีการแก้ไข |
If-None-Match
เมื่อใช้ส่วนหัว If-None-Match
เอนทิตีที่แคชไว้จะเป็นปัจจุบันหาก ETag ในส่วนหัวไม่ตรงกับ ETag ที่แคชไว้ ระบบจะส่งคำขอที่ไม่ใช่ GET ซึ่งมีส่วนหัวนี้ไปยังเซิร์ฟเวอร์ต้นทาง
หาก Edge ได้รับคําขอ GET ขาเข้าที่มีส่วนหัวนี้
หาก | จากนั้น |
---|---|
ส่วนหัว If-None-Match จะระบุ ETag อย่างน้อย 1 รายการ |
|
ส่วนหัว |
Edge แสดงสถานะ 304 ไม่มีการเปลี่ยนแปลง |
พบรายการแคชที่มี 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 ต่อท้ายคีย์แคชเพื่อให้คีย์มีความหมายมากขึ้นสำหรับรายการที่แคชไว้แต่ละรายการ ดูรายละเอียดเพิ่มเติมได้ที่ "การกำหนดค่าคีย์แคช" ในนโยบายแคชคำตอบ