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

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

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

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

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

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

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

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

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

کنترل حافظه پنهان

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

محدودیت‌های پشتیبانی از کنترل حافظه پنهان

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 مراجعه کنید.

دستورالعمل کنترل حافظه پنهان	چگونه Apigee Edge دستورالعمل را پردازش می‌کند
`cache-extension`	پشتیبانی نمی‌شود.
`max-age`	اگر سیاست ResponseCache شما عنصر `<UseResponseCacheHeaders>` را روی `true` تنظیم کند، پاسخ می‌تواند برای تعداد ثانیه‌های مشخص شده توسط این دستورالعمل ذخیره شود. این دستورالعمل توسط دستورالعمل `s-maxage` لغو می‌شود و هدر `Expires` را لغو می‌کند. همچنین می‌تواند توسط عنصر `<ExpirySettings>` مربوط به سیاست لغو شود. برای اطلاعات بیشتر، به «تنظیم انقضای ورودی کش» و `<UseResponseCacheHeaders>` در سیاست Response Cache مراجعه کنید. توجه: محتوایی که با استفاده از سیاست ResponseCache ذخیره می‌شود، مقدار max-age تعیین‌شده توسط مبدأ خود را حفظ می‌کند. این بدان معناست که هنگام بازیابی از حافظه پنهان، محتوا ممکن است قدیمی‌تر از مقدار max-age نشان داده‌شده باشد (قدیمی‌تر از آنچه کلاینت می‌داند).
`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، تنها استثنا برای این قانون زمانی است که پاسخ شامل یک هدر Authorization باشد.
`s-maxage`	اگر سیاست ResponseCache شما عنصر `<UseResponseCacheHeaders>` را روی `true` تنظیم کند، پاسخ می‌تواند برای تعداد ثانیه‌های مشخص شده توسط این دستورالعمل ذخیره شود. این دستورالعمل، دستورالعمل `max-age` و سرآیند `Expires` را لغو می‌کند. این دستورالعمل می‌تواند توسط عنصر `<ExpirySettings>` در سیاست لغو شود. برای اطلاعات بیشتر، به «تنظیم انقضای ورودی کش» و `<UseResponseCacheHeaders>` در سیاست Response Cache مراجعه کنید. توجه: محتوایی که با استفاده از سیاست 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 شرح داده شده‌اند. برای مثال:

انقضا: پنجشنبه، ۱ دسامبر ۱۹۹۴، ساعت ۱۶:۰۰:۰۰ به وقت گرینویچ

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

نکته: در حالی که بخش ۱۴.۲۱ از مشخصات نشان می‌دهد که مقدار Expires بیش از یک سال در آینده به این معنی است که یک ورودی کش هرگز منقضی نمی‌شود، Apigee چنین مقداری را به این معنی تفسیر می‌کند که ورودی باید تا تاریخ و زمان مشخص شده کش شود.

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

ای‌تگ

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

وقتی یک نقطه پایانی هدف، پاسخی را به همراه 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 درخواستی وجود دارد.	مرورگر اج وضعیت 304 «اصلاح نشده» را برمی‌گرداند
یک ورودی کش با همان URI درخواست پیدا می‌شود اما فقط حاوی ETag های ضعیف است.	قبل از اینکه Edge آن را به کلاینت برگرداند، ورودی باید توسط سرور مبدا مجدداً اعتبارسنجی شود.
Edge یک ETag از سرور مبدا دریافت می‌کند.	ETag بدون تغییر به کلاینت بازگردانده می‌شود.

اگر-اصلاح-شده-از

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

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

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

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

می‌توانید مقادیر سرآیند Accept را به کلیدهای کش اضافه کنید تا کلیدها برای هر مورد کش‌شده معنادارتر شوند. برای جزئیات بیشتر، به «پیکربندی کلید کش» در سیاست کش پاسخ مراجعه کنید.