Expires: Thu, 19 Nov 1981 08:52:00 GMT
header("Expires:" . date("r"));
# Заголовок Expires
<ifmodule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 30 days"
</ifmodule>
<META HTTP-EQUIV="expires" CONTENT="Wed, 26 Feb 2004 08:21:57 GMT">
| Цитата (Семён @ 4.11.2011 - 08:42) |
| te0203 У вас явно с английским плохо и делами оптимизации, Last-Modified - это не дата создания, это дата изменения страницы. |
| Цитата |
| 14.9.3 Modifications of the Basic Expiration Mechanism The expiration time of an entity MAY be specified by the origin server using the Expires header (see section 14.21). Alternatively, it MAY be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, more restrictive cache directive is also present. If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks. Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response does not include a Cache-Control header field, it SHOULD consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. |
CharsetOverrideExpires Off