HTTP 캐시

Cache-Control 헤더 ¶🎜

$date = new DateTime();
$date->modify('+600 seconds'); 
$response->setExpires($date);

Expires: Thu, 01 Mar 2011 16:00:00 GMT

공개 응답 및 비공개 응답 ¶

게이트웨이 캐시이든 프록시 캐시이든 캐시 콘텐츠가 더 많은 사용자에 의해 공유되기 때문에 "공유" 공유 캐시로 간주됩니다. "사용자별" 응답이 실수로 공유 캐시에 배치된 경우 나중에 여러 다른 사용자에게 반환될 수 있습니다. 귀하의 계정 정보가 캐시된 다음 계정 페이지를 요청한 모든 후속 사용자에게 전송된다면 어떨지 상상해 보십시오!

이 상황을 처리하려면 각 응답을 공개 또는 비공개로 설정해야 합니다.

public

은 응답이 공개 캐시와 비공개 캐시 모두로 캐시되어야 함을 나타냅니다.

private

은 응답 정보의 전체 또는 일부가 특정 사용자에게만 해당되므로 공개 캐싱에 대한 캐싱이 금지됨을 나타냅니다.

Symfony는 보수적으로 각 응답을 비공개로 설정합니다. 공유 캐시(예: Symfony 역방향 프록시)를 활용하려면 응답을 명시적으로 공개로 설정해야 합니다.

안전한 방법 ¶

HTTP 캐싱은 "안전한" HTTP 방법(예: GET 또는 HEAD)에서만 작동합니다. 소위 보안이란 요청에 대한 서비스(예: 로깅, 캐시 정보 처리 등)를 제공할 때 서버의 프로그램 상태를 절대 변경할 수 없음을 의미합니다. 이는 매우 설득력 있고 중요한 두 가지 결론으로 ​​이어집니다.

• GET 또는 HEAD 요청에 응답하여 프로그램 상태를 변경해서는 안 됩니다. 게이트웨이 캐시를 사용하지 않더라도 프록시 캐싱의 특성상 GET 또는 HEAD 요청이 실제로 서버에 도달할 수도 있고 그렇지 않을 수도 있습니다.

• PUT, POST 또는 DELETE 메서드를 캐시할 것으로 기대하지 마세요. 이러한 메서드는 애플리케이션 상태가 변경될 때(예: 블로그 게시물 삭제) 사용됩니다. 이를 캐싱하면 특정 요청이 프로그램에 도달하거나 변경되는 것을 방지할 수 있습니다.

캐싱 규칙 및 기본 설정 ¶

HTTP1.1에서는 Cache-Control 헤더가 명시적으로 지정되지 않는 한 기본적으로 모든 콘텐츠를 캐시할 수 있습니다. 실제로 대부분의 캐시는 요청에 쿠키가 포함된 경우, 인증 헤더가 포함된 경우, 안전하지 않은 메서드(예: PUT, POST 또는 DELETE)가 사용되는 경우 또는 응답에 리디렉션 상태 코드가 있는 경우 아무 작업도 수행하지 않습니다. Cache-Control头。实践中，多数缓存在请求中包含cookie时、包含authorization头时、使用了一个非安全方法时（比如PUT、POST或DELETE）或当响应有一个重定向状态码时，什么也不做。

当开发者在响应头中什么也没设置时，Symfony依据以下规则，自动设置了有意义的而且是偏保守的Cache-Header头。

• 如果没有缓存头信息被定义（Cache-Control、Expires、ETag或Last-Modified），Cache-Control将被设为no-cache，代表响应将不被缓存；

• 如果Cache-Control是空（但是另外一个缓存头有被设置），其值将被设为private, must-revalidate

  개발자가 응답 헤더에 아무것도 설정하지 않으면 Symfony는 다음 규칙에 따라 의미 있고 보수적인 Cache-Header 헤더를 자동으로 설정합니다. 🎜🎜🎜🎜캐시 헤더가 정의되지 않은 경우(Cache-Control, Expires, ETag 또는 Last-Modified) ), Cache-Control은 no-cache로 설정됩니다. 이는 응답이 캐시되지 않음을 의미합니다. 🎜🎜🎜🎜Cache-Control가 비어 있으면(다른 캐시 헤더가 설정됨) 해당 값은 private, must-revalidate로 설정됩니다.

• 그러나 하나 이상의 Cache-Control 지시문이 설정되어 있고 public 또는 private 지시문이 명시적으로 추가되지 않은 경우 Symfony는 자동으로 code>private 지시문(s-maxage가 설정된 경우 제외) Cache-Control指令被设置，而且没有public或private指令被显式添加的话，Symfony会自动添加private指令（除了当s-maxage被设置时）

HTTP Expiration,Validation和Invalidation ¶

HTTP协议定义了两种缓存模型：

• 利用expiration model（过期模型），通过包容Cache-Control头和/或Expires头，即可直接指定一个响应应该被认为“新鲜”的时长。缓存能够理解过期时间，不再制造相同请求，直到该缓存版本抵达过期时间，而且变得“不新鲜（stale）”。

• 当页面是真动态时（展现层经常改变），则validation model（验证模型）的使用就十分有必要。利用这个模型，缓存把响应存储起来，但会在每次请求时向服务器“提问”——是否缓存了的响应仍然有效？程序使用了一个独立的响应识别器（即Etag头）和/或一个时间戳（即Last-Modified

HTTP 만료, 유효성 검사 및 무효화 ¶

Expiration(만료) ¶

expiration 모델은 두 캐싱 모델 중 더 효율적이고 직접적인 모델이므로 최대한 많이 사용해야 합니다. . 만료를 통해 응답이 캐시되면 캐시는 응답을 저장하고 프로그램을 실행하지 않고도 만료 직전에 응답을 반환합니다.

만료 모델은 거의 동일한 두 HTTP 헤더인 Expires 또는 Cache-Control 중 하나를 통해 구현할 수 있습니다. Expires或Cache-Control。

使用Expires头控制过期 ¶

根据HTTP specification，“Expires头字段将在response被认为是stale之后给出date/time。”。这里的Expires头可以被设为Response方法：setExpires()。它使用DateTime实例作为参数：

// Sets the number of seconds after which the response
// should no longer be considered fresh// 设置“响应过期”的秒数$response->setMaxAge(600);
 // Same as above but only for shared caches
// 同上，但仅用于共享缓存$response->setSharedMaxAge(600);

该响应的HTTP头信息类似这种：

1

setExpires()方法将自动转换日期为GMT时区，因为这是HTTP specification的要求。

注意，在HTTP 1.1版之前，并不需要原始服务器来发送Date头。因此，缓存（比如浏览器的）就需要本地时钟来评估Expires头，进而令缓存周期的计算因时间倾斜而变得脆弱不堪。另外一个Expires头限制是，正如HTTP协议中所描述的，“HTTP/1.1 不得发送Expires的日期超过一年。”

使用Cache-Control头控制过期 ¶

因为Expires头的限制，多数情况下，你应该使用Cache-Control头来替代。记得，Cache-Control头被用于多种不同的缓存指令。例如，max-age和s-maxage。第一个用于全部缓存，而第二个仅在共享缓存时用到。

Cache-Control: max-age=600, s-maxage=600

Cache-Control

// Marks the Response stale 标记响应过期$response->expire(); 
// Force the response to return a proper 304 response with no content
// 强制响应返回一个没有内容的恰当的304响应$response->setNotModified();

// Set cache settings in one call$response->setCache(array(
    'etag'          => $etag,
    'last_modified' => $date,
    'max_age'       => 10,
    's_maxage'      => 10,
    'public'        => true,
    // 'private'    => true,
    ));

만료 및 유효성 검사 ¶

물론 동일한 응답에 응답할 수 있습니다. >둘 다 사용 검증 및 만료. 만료의 이점이 검증보다 중요하므로 두 가지 장점을 모두 쉽게 누릴 수 있습니다. 즉, 만료와 유효성 검사를 함께 사용하면 캐시에 캐시된 콘텐츠를 제공하도록 지시하는 동시에 특정 간격(만료)으로 역방향을 확인하여 캐시된 콘텐츠가 여전히 유효한지 확인할 수 있습니다. Response同时使用validation和expiration。因为expiration的优势大过validation，你能很容易地从两个世界中好的一面受益。也就是说，同时使用过期和验证，你可以命令缓存来服务于已缓存的内容，同时还能在某些区间（expiration）向后检查以确认缓存内容仍然有效。

更多Response方法 ¶

Response类提供了很多方法以应对缓存。下面是几个特别有用的：

另外，多数与缓存相关的HTTP头可以单独使用setCache()