主题：【讨论】apache 设定压缩传送和缓存控制的一些问题 -- 铁手

A user agent that wishes to authenticate itself with a server--

usually, but not necessarily, after receiving a 401 response--does

so by including an Authorization request-header field with the

request. The Authorization field value consists of credentials

containing the authentication information of the user agent for

the realm of the resource being requested.

Authorization = "Authorization" ":" credentials

HTTP access authentication is described in "HTTP Authentication:

Basic and Digest Access Authentication" [43]. If a request is

authenticated and a realm specified, the same credentials SHOULD

be valid for all other requests within this realm (assuming that

the authentication scheme itself does not require otherwise, such

as credentials that vary according to a challenge value or using

synchronized clocks).

When a shared cache (see section 13.7) receives a request

containing an Authorization field, it MUST NOT return the

corresponding response as a reply to any other request, unless one

of the following specific exceptions holds:

1. If the response includes the "s-maxage" cache-control

directive, the cache MAY use that response in replying to a

subsequent request. But (if the specified maximum age has

passed) a proxy cache MUST first revalidate it with the origin

server, using the request-headers from the new request to allow

the origin server to authenticate the new request. (This is the

defined behavior for s-maxage.) If the response includes "s-

maxage=0", the proxy MUST always revalidate it before re-using

it.

2. If the response includes the "must-revalidate" cache-control

directive, the cache MAY use that response in replying to a

subsequent request. But if the response is stale, all caches

MUST first revalidate it with the origin server, using the

request-headers from the new request to allow the origin server

to authenticate the new request.

3. If the response includes the "public" cache-control directive,

it MAY be returned in reply to any subsequent request.

By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Section 13.4 summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override the default cacheability of a response:

public

Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared cache. (See also Authorization, section 14.8, for additional details.)

private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the

response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.

Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.

no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.

If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

Note: Most HTTP/1.0 caches will not recognize or obey this directive.