این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

پشتیبانی از هدرهای پاسخ HTTP

شما در حال مشاهده اسناد Apigee Edge هستید.
به مستندات Apigee X بروید . اطلاعات

این مبحث توضیح می‌دهد که Edge چگونه هدرهای ذخیره‌سازی HTTP/1.1 را هنگام استفاده از خط‌مشی ResponseCache مدیریت می‌کند. Apigee Edge در حال حاضر از زیرمجموعه‌ای از هدرها و دستورالعمل‌های ذخیره‌سازی HTTP/1.1 (ویژگی‌های پشتیبانی‌نشده در این مبحث فهرست شده‌اند) پشتیبانی می‌کند که از سرورهای هدف (منبع) باطن دریافت می‌شوند.

علاوه بر این، با هدرهای خاص، Edge بر اساس دستورالعمل های آنها اقدام می کند. در برخی موارد، این هدرهای حافظه پنهان HTTP/1.1 هر رفتاری را که در خط مشی ResponseCache مشخص شده است، لغو می کنند. برای مثال، اگر هدر Cache-Control از یک سرور باطن بازگردانده شود، می‌توانید دستور s-maxage سرصفحه را به طور بالقوه نادیده بگیرید سایر تنظیمات انقضا در خط‌مشی.

توجه: مشخصات HTTP/1.1 سرصفحه‌های کش استاندارد و مکانیسم‌های کنترلی را توصیف می‌کند که از کش در طول زنجیره درخواست/پاسخ HTTP پشتیبانی می‌کنند. این سربرگ ها و مکانیسم ها اطلاعاتی در مورد منابع ذخیره شده در حافظه پنهان ارائه می دهند. آنها همچنین به سرورها کمک می کنند تا نحوه مدیریت داده های کش را تعیین کنند. مشخصات خود حاوی اطلاعات دقیق در مورد حافظه پنهان در HTTP است. همچنین بسیاری از وبلاگ ها، مقاله ها و منابع دیگری در اینترنت موجود است که کش HTTP را توضیح می دهد.

توجه: استفاده از هدرها برای تأثیرگذاری بر کلیدهای حافظه پنهان و TTL ورودی حافظه پنهان، هنگام ساخت کلیدهای حافظه پنهان پاسخ و تنظیم TTL ورودی حافظه پنهان، می توانید از هدر پاسخ Edge استفاده کنید. برای انجام این کار، از این عناصر پرچم سیاست ResponseCache استفاده می کنید:

<UseResponseCacheHeaders> -- وقتی این مقدار روی true تنظیم شود، Edge سرصفحه های پاسخ HTTP را در نظر می گیرد که هنگام تنظیم "زمان زنده بودن" (TTL) پاسخ در حافظه پنهان استفاده می شود. برای جزئیات، به "تنظیم انقضای ورودی حافظه پنهان" و <UseResponseCacheHeaders> در خط مشی Response Cache مراجعه کنید.
<UseAcceptHeader> - وقتی این مقدار روی true تنظیم شود، Edge از هدرهای Accept پاسخ برای تقویت کلید حافظه پنهان استفاده می کند. برای اطلاعات بیشتر، <UseAcceptHeader> را در سیاست کش پاسخ ببینید.

سربرگ	پشتیبانی کنید
Cache-Control	در پاسخ‌های برگشتی از سرورهای مبدا باطن پشتیبانی می‌شود، اما نه درخواست‌های مشتری. Edge از زیر مجموعه ای از دستورالعمل ها پشتیبانی می کند.
منقضی می شود	پشتیبانی می شود. قابل رد شدن است.
برچسب های موجودیت (ETags)	رفتار خاص برای If-Match و If-None-Match .
If-Modified-Since	در درخواست‌های GET، هدر به سرور مبدا ارسال می‌شود، حتی اگر یک ورودی حافظه پنهان معتبر وجود داشته باشد.
پذیرش-رمزگذاری	Edge بسته به هدرهای ورودی، پاسخ‌های فشرده یا غیرفشرده را ارسال می‌کند.

Cache-Control

Apigee Edge از هدر Cache-Control فقط در پاسخ‌هایی که از سرورهای اصلی باطن بازگردانده می‌شوند پشتیبانی می‌کند (مشخصات HTTP/1.1 به هدرهای Cache-Control در درخواست‌های مشتری و پاسخ‌های سرور مبدا اجازه می‌دهد). سرورهای مبدأ می توانند هر دو نقطه پایانی هدف تعریف شده در یک پراکسی Apigee Edge API و آنهایی که با استفاده از فراخوانی TargetServer API ایجاد شده اند را شامل شوند.

محدودیت های پشتیبانی 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 برای دستورالعمل‌های هدر پاسخ HTTP Cache-Control را توضیح می‌دهد.

برای اطلاعات دقیق تر در مورد دستورالعمل های فهرست شده در اینجا، Cache-Control را در مشخصات HTTP/1.1 ببینید.

دستورالعمل Cache-Control	چگونه Apigee Edge دستورالعمل را پردازش می کند
`cache-extension`	پشتیبانی نمی شود.
`max-age`	اگر خط مشی ResponseCache شما عنصر `<UseResponseCacheHeaders>` را روی `true` تنظیم کند، پاسخ را می توان برای تعداد ثانیه های مشخص شده توسط این دستورالعمل ذخیره کرد. این دستورالعمل توسط دستورالعمل `s-maxage` لغو می شود و سربرگ `Expires` را لغو می کند. همچنین می‌تواند توسط عنصر `<ExpirySettings>` خط‌مشی لغو شود. برای اطلاعات بیشتر، به «تنظیم انقضای ورودی حافظه پنهان» و `<UseResponseCacheHeaders>` در سیاست پاسخ کش مراجعه کنید. توجه: محتوای ذخیره‌شده در حافظه پنهان با خط‌مشی ResponseCache، مقدار حداکثر سنی را که بر اساس مبدأ آن تعیین شده است، حفظ می‌کند. این بدان معناست که وقتی محتوا از حافظه پنهان بازیابی می‌شود، ممکن است از مقدار حداکثر سنی که نشان می‌دهد قدیمی‌تر باشد (قدیمی‌تر از آن چیزی که مشتری می‌داند).
`must-revalidate`	پشتیبانی نمی شود. تمام ورودی های کش به محض انقضا توسط Apigee Edge حذف می شوند.
`no-cache`	Edge پاسخ مبدا را در حافظه پنهان ذخیره می‌کند، اما قبل از استفاده برای برآورده کردن درخواست‌های مشتری بعدی، باید مجدداً با سرور مبدا تأیید شود. این قانون به مبدأ اجازه می دهد تا یک پاسخ 304 Not Modified را برگرداند تا نشان دهد که پاسخ باید از حافظه پنهان بازگردانده شود، بنابراین پردازش مورد نیاز برای بازگرداندن کل پاسخ ذخیره می شود. اگر سرور مبدا یک پاسخ کامل را برگرداند، ورودی کش موجود را جایگزین می کند. هر نام فیلد مشخص شده با این دستورالعمل نادیده گرفته می شود. توجه: هدر HTTP/1.0، `Pragma: no-cache` معادل `Cache-Control: no-cache` تلقی می شود.
`no-store`	پشتیبانی نمی شود.
`no-transform`	پشتیبانی نمی شود.
`private`	پشتیبانی نمی شود. اگر این دستورالعمل دریافت شود، پاسخ مبدا ذخیره نمی شود. هر نام فیلد نادیده گرفته می شود.
`proxy-revalidate`	پشتیبانی نمی شود. تمام ورودی های کش به محض انقضا توسط Apigee Edge حذف می شوند.
`public`	Edge پاسخ مبدا را در حافظه پنهان نگه می دارد، حتی زمانی که دستورالعمل های دیگر خلاف آن را نشان می دهند. طبق مشخصات HTTP/1.1، تنها استثنای این قاعده در صورتی است که پاسخ شامل یک عنوان مجوز باشد.
`s-maxage`	اگر خط مشی ResponseCache شما عنصر `<UseResponseCacheHeaders>` را روی `true` تنظیم کند، پاسخ را می توان برای تعداد ثانیه های مشخص شده توسط این دستورالعمل ذخیره کرد. این دستورالعمل دستور `max-age` و سرصفحه `Expires` را لغو می کند. می‌تواند توسط عنصر `<ExpirySettings>` خط‌مشی لغو شود. برای اطلاعات بیشتر، به «تنظیم انقضای ورودی حافظه پنهان» و `<UseResponseCacheHeaders>` در سیاست پاسخ کش مراجعه کنید. توجه: محتوای ذخیره‌شده در حافظه پنهان با خط‌مشی ResponseCache مقدار s-maxage تعیین‌شده توسط مبدا خود را حفظ می‌کند. این بدان معناست که وقتی محتوا از حافظه پنهان بازیابی می‌شود، ممکن است قدیمی‌تر از مقدار s-maxage آن باشد (قدیمی‌تر از آن چیزی که مشتری می‌داند).

منقضی می شود

وقتی پرچم UseResponseCacheHeaders در خط‌مشی ResponseCache روی true تنظیم می‌شود، Edge می‌تواند از سرصفحه Expires برای تعیین زمان ماندگاری (TTL) یک ورودی ذخیره‌شده استفاده کند. این هدر تاریخ/زمانی را مشخص می‌کند که پس از آن ورودی حافظه پنهان پاسخ، قدیمی در نظر گرفته می‌شود. این هدر به سرورها اجازه می‌دهد تا زمانی که مشکلی برای برگرداندن یک مقدار ذخیره‌شده بر اساس مهر زمانی ندارد، سیگنال دهند.

توجه: دستورات هدر Cache-Control max-age و s-maxage بر سرصفحه Expires اولویت دارند و نادیده می گیرند. برای اطلاعات بیشتر، به «تنظیم انقضای ورودی حافظه پنهان» و <UseResponseCacheHeaders> در خط مشی Response Cache مراجعه کنید.

قالب‌های تاریخ قابل قبول برای سرصفحه Expires در مشخصات HTTP/1.1 توضیح داده شده است. به عنوان مثال:

انقضا: پنجشنبه، 01 دسامبر 1994، ساعت 16:00:00 GMT

برای اطلاعات دقیق در مورد قالب‌های تاریخ/زمان HTTP، به فرمت‌های تاریخ/زمان در مشخصات HTTP/1.1 مراجعه کنید.

توجه: در حالی که بخش 14.21 مشخصات نشان می‌دهد که مقدار Expires بیش از یک سال در آینده به این معنی است که یک ورودی حافظه پنهان هرگز منقضی نمی‌شود، Apigee چنین مقداری را به این معنا تفسیر می‌کند که ورودی باید تا تاریخ و زمان مشخص شده ذخیره شود.

برای اطلاعات بیشتر در مورد هدر Expires ، به تعاریف فیلد سرصفحه در مشخصات HTTP/1.1 مراجعه کنید.

ETag

تگ موجودیت (ETag) یک شناسه مرتبط با یک منبع درخواستی است. با استفاده از ETag، سرور می تواند تعیین کند که آیا منبع درخواستی و منبع ذخیره شده مرتبط با آن مطابقت دارند یا خیر. به عنوان مثال، سرور می‌تواند پاسخ را در صورت عدم مطابقت با آنچه که در حال حاضر در حافظه پنهان است، ذخیره کند. اگر تگ های ET مطابقت داشته باشند، می تواند منبع ذخیره شده را برگرداند.

هنگامی که یک نقطه پایانی هدف، پاسخی را با ETag به Edge ارسال می کند، Edge ETag را همراه با پاسخ ذخیره می کند.

می توانید اطلاعات بیشتری در مورد برچسب های نهاد در پارامترهای پروتکل در مشخصات HTTP/1.1 بخوانید.

اگر-مچ

با هدر درخواست If-Match ، اگر ETag در هدر با ETag ذخیره شده مطابقت داشته باشد، یک موجودیت ذخیره شده در حافظه پنهان جاری است. هر درخواستی غیر از GET که هدر If-Match مشخص می‌کند به سرور مبدا ارسال می‌شود تا اطمینان حاصل شود که امکانات ذخیره‌سازی مبدا فرصتی برای پردازش درخواست دارند.

می توانید اطلاعات بیشتری در مورد If-Match در تعاریف فیلد سرصفحه در مشخصات HTTP/1.1 بخوانید.

اگر Edge یک درخواست GET ورودی از یک کلاینت دریافت کند که شامل سرصفحه If-Match است:

اگر	سپس
هدر `If-Match` یک یا چند ETag را مشخص می کند	Apigee Edge هر ورودی کش منقضی نشده را برای منبع مشخص شده بازیابی می کند و هر ETag قوی روی آن ورودی های کش شده را با موارد مشخص شده در هدر `If-Match` مقایسه می کند. اگر مطابقت یافت شود، ورودی حافظه پنهان برگردانده می شود. اگر نه، درخواست به سرور مبدا ارسال می شود.
هدر `If-Match` "*" را مشخص می کند	درخواست به سرور مبدا ارسال می شود تا اطمینان حاصل شود که هر گونه امکانات کش مبدا فرصتی برای پردازش درخواست دارد
یک ورودی حافظه پنهان با همان URI درخواست یافت می شود، اما فقط حاوی ETag های ضعیف است	ورودی باید قبل از بازگرداندن به مشتری توسط سرور مبدا تأیید شود
ETag ها از سرور مبدا می آیند.	ETag بدون تغییر به مشتری بازگردانده می شود

اگر-هیچ-تطابق

با هدر If-None-Match ، اگر ETag در هدر با ETag ذخیره شده مطابقت نداشته باشد، موجودیت ذخیره شده در حافظه پنهان جاری است. درخواست‌هایی غیر از GET که حاوی این هدر هستند به سرور مبدا ارسال می‌شوند.

اگر Edge یک درخواست GET ورودی با این هدر دریافت کند:

اگر	سپس
هدر `If-None-Match` یک یا چند ETag را مشخص می کند	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 بدون تغییر به مشتری بازگردانده می شود

If-Modified-Since

اگر Apigee Edge یک هدر If-Modified-Since را در یک درخواست GET دریافت کند، حتی اگر یک ورودی کش معتبر وجود داشته باشد، به سرور مبدا ارسال می شود.

این تضمین می کند که هر به روز رسانی منبعی که از Apigee Edge عبور نکرده است، حساب می شود. اگر سرور مبدا یک موجودیت جدید را برگرداند، Edge ورودی حافظه پنهان موجود را با مقدار جدید جایگزین می‌کند. اگر سرور وضعیت 304 Not Modified را برگرداند، Edge مقدار پاسخ را برمی‌گرداند اگر هدر Last-Modified پاسخ ذخیره شده نشان دهد که تغییر نکرده است.

پذیرش-رمزگذاری

هنگامی که یک درخواست دریافتی شامل هدر Accept-Encoding با مقادیر gzip ، deflate یا compress ، سرور مبدا با داده های فشرده پاسخ می دهد. هنگامی که درخواست‌های بعدی بدون هدرهای Accept-Encoding ارائه می‌شوند، انتظار پاسخ غیرفشرده را دارند. مکانیسم ذخیره پاسخ Apigee قادر است هر دو پاسخ فشرده و غیر فشرده را بسته به هدرهای ورودی بدون بازگشت به سرور مبدا ارسال کند.

می‌توانید مقادیر سرصفحه Accept را به کلیدهای حافظه پنهان اضافه کنید تا کلیدها برای هر مورد ذخیره‌شده معنی‌دارتر شوند. برای جزئیات بیشتر، به "پیکربندی یک کلید حافظه پنهان" در سیاست کش پاسخ مراجعه کنید.