HTTP 快取過期
expiration model 是兩種快取模型中最有效率且最直接的模型，應盡可能使用。當回應使用過期時間快取時，快取會直接傳回，而不會點擊應用程式，直到快取的回應過期。
過期模型可以使用兩個幾乎相同的 HTTP Header 之一來完成：Expires 或 Cache-Control。
使用 Cache-Control Header 過期
大多數時候，您將使用 Cache-Control Header，它用於指定許多不同的快取指示
1 2 3 4 5 6 7 8
use Symfony\Component\HttpKernel\Attribute\Cache;
// ...
#[Cache(public: true, maxage: 600)]
public function index(): Response
{
// ...
}Cache-Control Header 將採用以下格式（可能還有其他指示）
1
Cache-Control: public, max-age=600注意
使用 setSharedMaxAge() 方法不等同於同時使用 setPublic() 和 setMaxAge() 方法。根據 RFC 7234 的 Serving Stale Responses 章節，s-maxage 設定（由 setSharedMaxAge() 方法新增）禁止快取在 stale-if-error 情境中使用過時的回應。這就是為什麼建議同時使用 public 和 max-age 指示。
使用 Expires Header 過期
Cache-Control Header 的替代方案是 Expires。兩者之間沒有優缺點。
根據 HTTP 規範，「Expires Header 欄位給出了回應被視為過時的日期/時間。」可以使用 #[Cache] 屬性的 expires 選項或 setExpires() Response 方法來設定 Expires Header
1 2 3 4 5 6 7 8
use Symfony\Component\HttpKernel\Attribute\Cache;
// ...
#[Cache(expires: '+600 seconds')]
public function index(): Response
{
// ...
}產生的 HTTP Header 將如下所示
1
Expires: Thu, 01 Mar 2011 16:00:00 GMT注意
expires 選項和 setExpires() 方法會自動將日期轉換為 GMT 時區，這是規範所要求的。
請注意，在 1.1 之前的 HTTP 版本中，原始伺服器不需要傳送 Date Header。因此，快取（例如瀏覽器）可能需要依賴本機時鐘來評估 Expires Header，這使得生命週期計算容易受到時鐘偏差的影響。Expires Header 的另一個限制是，規範指出「HTTP/1.1 伺服器不應傳送未來一年以上的 Expires 日期。」
注意
根據 RFC 7234 的 Calculating Freshness Lifetime 章節，當定義了 Cache-Control Header 的 s-maxage 或 max-age 指示時，Expires Header 值會被忽略。