about Cache-Control

더 읽 기
      Cache-Control 에 관 한 글 을 보 았 습 니 다.2002 년 의 글 임 에 도 불구 하고 좋 습 니 다.다음 과 같은 기록 이 라 고 할 수 있 습 니 다.혁 혁!Cache-Control 의 각 속성 과 용법,그리고 HTTP/1.0 에서 만 지원 하 는'Pragma:no-cache'는 HTTP/1.1'Cache-Control:private'와 같은 가격 으로 더 많은 것 을 여러분 이 직접 보 세 요.
 
 
 
Any valid HTTP headers can be put in these files. This provides another way to apply the Expires header, and it's a way to add the Cache-Control headers. The relevant Cache-Control headers are: Cache-Control : max-age = [delta-seconds]
Modifies the expiration mechanism, overriding the Expires header. Max-age implies Cache-Control : public. Cache-Control : public
Indicates that the object may be stored in a cache. This is the default. Cache-Control : private Cache-Control : private = [field-name]
Indicates that the object (or specified field) must not be stored in a shared cache and is intended for a single user. It may be stored in a private cache. Cache-Control : no-cache Cache-Control : no-cache = [field-name]
Indicates that the object (or specified field) may be cached, but may not be served to a client unless revalidated with the origin server. Cache-Control : no-store
Indicates that the item must not be stored in nonvolatile storage, and should be removed as soon as possible from volatile storage. Cache-Control : no-transform
Proxies may convert data from one storage system to another. This directive indicates that (most of) the response must not be transformed. (The RFC allows for transformation of some fields, even with this header present.) Cache-Control : must-revalidate Cache-Control : proxy-revalidate
Forces the proxy to revalidate the page even if the client will accept a stale response. Read the RFC before using these headers, there are restrictions on their use.
Caveats and gotchas

HTTP/1.0 has minimal cache control and only understands the Pragma: no-cache header. Caches using HTTP/1.0 will ignore the Expires and Cache-Control headers.

None of the Cache-Control directives ensure privacy or security of data. The directives "private" and "no-store" assist in privacy and security, but they are not intended to substitute for authentication and encryption.

This article is not a substitute for the RFC. If your are implementing the Cache-Control headers, do read the RFC for a detailed description of what each header means and what the limits are.