You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@labs.apache.org by fi...@apache.org on 2007/10/09 02:35:38 UTC
svn commit: r583020 [7/8] - in /labs/webarch/trunk/http/draft-fielding-http:
p1-messaging.xml p2-semantics.xml p3-payload.xml p4-conditional.xml
p5-range.xml p6-cache.xml p7-auth.xml
Modified: labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml?rev=583020&r1=583019&r2=583020&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p6-cache.xml Mon Oct 8 17:35:37 2007
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc [
<!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
@@ -11,6 +11,19 @@
<!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
<!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
<!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
+ <!ENTITY messaging "[Part 1]">
+ <!ENTITY combining-byte-ranges "[Part 5]">
+ <!ENTITY entity-length "[Part 3]">
+ <!ENTITY entity-tags "[Part 4]">
+ <!ENTITY full-date "[Part 1]">
+ <!ENTITY header-authorization "[Part 7]">
+ <!ENTITY header-connection "[Part 1]">
+ <!ENTITY header-date "[Part 1]">
+ <!ENTITY weak-and-strong-validators "[Part 4]">
+ <!ENTITY message-headers "[Part 1]">
+ <!ENTITY message-length "[Part 1]">
+ <!ENTITY safe-methods "[Part 2]">
+ <!ENTITY server-driven-negotiation "[Part 3]">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
@@ -20,11 +33,12 @@
<?rfc editing="no" ?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-references-in-index="yes" ?>
-<rfc number="2616" category="std" obsoletes="2068" xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit" >
-<x:assign-section-number number="18" builtin-target="authors"/>
+<rfc obsoletes="2068, 2616, 2617" category="std"
+ ipr="full3667" docName="draft-fielding-http-p6-cache-00"
+ xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
<front>
- <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+ <title abbrev="HTTP/1.1, part 6">HTTP/1.1, part 6: Caching</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
@@ -126,88 +140,28 @@
</address>
</author>
- <date month="June" year="1999"/>
+ <date month="September" year="2007"/>
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
- systems. It is a generic, stateless, protocol which can be used for
- many tasks beyond its use for hypertext, such as name servers and
- distributed object management systems, through extension of its
- request methods, error codes and headers <xref target="RFC2324"/>. A feature of HTTP is
- the typing and negotiation of data representation, allowing systems
- to be built independently of the data being transferred.
-</t>
-<t>
- HTTP has been in use by the World-Wide Web global information
- initiative since 1990. This specification defines the protocol
- referred to as "HTTP/1.1", and is an update to RFC 2068 <xref target="RFC2068"/>.
+ systems. HTTP has been in use by the World Wide Web global information
+ initiative since 1990. This document is Part 6 of the eight-part specification
+ that defines the protocol referred to as "HTTP/1.1" and, taken together,
+ updates RFC 2616 and RFC 2617. Part 4 defines requirements on HTTP caches
+ and the associated header fields that control cache behavior or indicate
+ cacheable response messages.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
-
-<section title="Purpose">
<t>
- The Hypertext Transfer Protocol (HTTP) is an application-level
- protocol for distributed, collaborative, hypermedia information
- systems. HTTP has been in use by the World-Wide Web global
- information initiative since 1990. The first version of HTTP,
- referred to as HTTP/0.9, was a simple protocol for raw data transfer
- across the Internet. HTTP/1.0, as defined by RFC 1945 <xref target="RFC1945"/>, improved
- the protocol by allowing messages to be in the format of MIME-like
- messages, containing metainformation about the data transferred and
- modifiers on the request/response semantics. However, HTTP/1.0 does
- not sufficiently take into consideration the effects of hierarchical
- proxies, caching, the need for persistent connections, or virtual
- hosts. In addition, the proliferation of incompletely-implemented
- applications calling themselves "HTTP/1.0" has necessitated a
- protocol version change in order for two communicating applications
- to determine each other's true capabilities.
-</t>
-<t>
- This specification defines the protocol referred to as "HTTP/1.1".
- This protocol includes more stringent requirements than HTTP/1.0 in
- order to ensure reliable implementation of its features.
-</t>
-<t>
- Practical information systems require more functionality than simple
- retrieval, including search, front-end update, and annotation. HTTP
- allows an open-ended set of methods and headers that indicate the
- purpose of a request <xref target="RFC2324"/>. It builds on the discipline of reference
- provided by the Uniform Resource Identifier (URI) <xref target="RFC1630"/>, as a location
- (URL) <xref target="RFC1738"/> or name (URN) <xref target="RFC1737"/>, for indicating the resource to which a
- method is to be applied. Messages are passed in a format similar to
- that used by Internet mail <xref target="RFC822"/> as defined by the Multipurpose
- Internet Mail Extensions (MIME) <xref target="RFC2045"/>.
-</t>
-<t>
- HTTP is also used as a generic protocol for communication between
- user agents and proxies/gateways to other Internet systems, including
- those supported by the SMTP <xref target="RFC821"/>, NNTP <xref target="RFC977"/>, FTP <xref target="RFC959"/>, Gopher <xref target="RFC1436"/>,
- and WAIS <xref target="WAIS"/> protocols. In this way, HTTP allows basic hypermedia
- access to resources available from diverse applications.
-</t>
-</section>
-
-<section title="Requirements">
-<t>
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 <xref target="RFC2119"/>.
-</t>
-<t>
- An implementation is not compliant if it fails to satisfy one or more
- of the &MUST; or &REQUIRED; level requirements for the protocols it
- implements. An implementation that satisfies all the &MUST; or &REQUIRED;
- level and all the &SHOULD; level requirements for its protocols is said
- to be "unconditionally compliant"; one that satisfies all the &MUST;
- level requirements but not all the &SHOULD; level requirements for its
- protocols is said to be "conditionally compliant."
+ This document will define aspects of HTTP related to caching response
+ messages. Right now it only includes the extracted relevant sections
+ of <xref target="RFC2616">RFC 2616</xref> without edit.
</t>
-</section>
<section title="Terminology">
<t>
@@ -215,197 +169,6 @@
played by participants in, and objects of, the HTTP communication.
</t>
<t>
- <iref item="connection"/>
- <x:dfn>connection</x:dfn>
- <list>
- <t>
- A transport layer virtual circuit established between two programs
- for the purpose of communication.
- </t>
- </list>
-</t>
-<t>
- <iref item="message"/>
- <x:dfn>message</x:dfn>
- <list>
- <t>
- The basic unit of HTTP communication, consisting of a structured
- sequence of octets matching the syntax defined in <xref target="httpmessage"/> and
- transmitted via the connection.
- </t>
- </list>
-</t>
-<t>
- <iref item="request"/>
- <x:dfn>request</x:dfn>
- <list>
- <t>
- An HTTP request message, as defined in <xref target="request"/>.
- </t>
- </list>
-</t>
-<t>
- <iref item="response"/>
- <x:dfn>response</x:dfn>
- <list>
- <t>
- An HTTP response message, as defined in <xref target="response"/>.
- </t>
- </list>
-</t>
-<t>
- <iref item="resource"/>
- <x:dfn>resource</x:dfn>
- <list>
- <t>
- A network data object or service that can be identified by a URI,
- as defined in <xref target="uri"/>. Resources may be available in multiple
- representations (e.g. multiple languages, data formats, size, and
- resolutions) or vary in other ways.
- </t>
- </list>
-</t>
-<t>
- <iref item="entity"/>
- <x:dfn>entity</x:dfn>
- <list>
- <t>
- The information transferred as the payload of a request or
- response. An entity consists of metainformation in the form of
- entity-header fields and content in the form of an entity-body, as
- described in <xref target="entity"/>.
- </t>
- </list>
-</t>
-<t>
- <iref item="representation"/>
- <x:dfn>representation</x:dfn>
- <list>
- <t>
- An entity included with a response that is subject to content
- negotiation, as described in <xref target="content.negotiation"/>. There may exist multiple
- representations associated with a particular response status.
- </t>
- </list>
-</t>
-<t>
- <iref item="content negotiation"/>
- <x:dfn>content negotiation</x:dfn>
- <list>
- <t>
- The mechanism for selecting the appropriate representation when
- servicing a request, as described in <xref target="content.negotiation"/>. The
- representation of entities in any response can be negotiated
- (including error responses).
- </t>
- </list>
-</t>
-<t>
- <iref item="variant"/>
- <x:dfn>variant</x:dfn>
- <list>
- <t>
- A resource may have one, or more than one, representation(s)
- associated with it at any given instant. Each of these
- representations is termed a `varriant'. Use of the term `variant'
- does not necessarily imply that the resource is subject to content
- negotiation.
- </t>
- </list>
-</t>
-<t>
- <iref item="client"/>
- <x:dfn>client</x:dfn>
- <list>
- <t>
- A program that establishes connections for the purpose of sending
- requests.
- </t>
- </list>
-</t>
-<t>
- <iref item="user agent"/>
- <x:dfn>user agent</x:dfn>
- <list>
- <t>
- The client which initiates a request. These are often browsers,
- editors, spiders (web-traversing robots), or other end user tools.
- </t>
- </list>
-</t>
-<t>
- <iref item="server"/>
- <x:dfn>server</x:dfn>
- <list>
- <t>
- An application program that accepts connections in order to
- service requests by sending back responses. Any given program may
- be capable of being both a client and a server; our use of these
- terms refers only to the role being performed by the program for a
- particular connection, rather than to the program's capabilities
- in general. Likewise, any server may act as an origin server,
- proxy, gateway, or tunnel, switching behavior based on the nature
- of each request.
- </t>
- </list>
-</t>
-<t>
- <iref item="origin server"/>
- <x:dfn>origin server</x:dfn>
- <list>
- <t>
- The server on which a given resource resides or is to be created.
- </t>
- </list>
-</t>
-<t>
- <iref item="proxy"/>
- <x:dfn>proxy</x:dfn>
- <list>
- <t>
- An intermediary program which acts as both a server and a client
- for the purpose of making requests on behalf of other clients.
- Requests are serviced internally or by passing them on, with
- possible translation, to other servers. A proxy &MUST; implement
- both the client and server requirements of this specification. A
- "transparent proxy" is a proxy that does not modify the request or
- response beyond what is required for proxy authentication and
- identification. A "non-transparent proxy" is a proxy that modifies
- the request or response in order to provide some added service to
- the user agent, such as group annotation services, media type
- transformation, protocol reduction, or anonymity filtering. Except
- where either transparent or non-transparent behavior is explicitly
- stated, the HTTP proxy requirements apply to both types of
- proxies.
- </t>
- </list>
-</t>
-<t>
- <iref item="gateway"/>
- <x:dfn>gateway</x:dfn>
- <list>
- <t>
- A server which acts as an intermediary for some other server.
- Unlike a proxy, a gateway receives requests as if it were the
- origin server for the requested resource; the requesting client
- may not be aware that it is communicating with a gateway.
- </t>
- </list>
-</t>
-<t>
- <iref item="tunnel"/>
- <x:dfn>tunnel</x:dfn>
- <list>
- <t>
- An intermediary program which is acting as a blind relay between
- two connections. Once active, a tunnel is not considered a party
- to the HTTP communication, though the tunnel may have been
- initiated by an HTTP request. The tunnel ceases to exist when both
- ends of the relayed connections are closed.
- </t>
- </list>
-</t>
-<t>
<iref item="cache"/>
<x:dfn>cache</x:dfn>
<list>
@@ -530,10785 +293,2171 @@
</t>
</list>
</t>
-<t>
- <iref item="upstream"/>
- <iref item="downstream"/>
- <x:dfn>upstream</x:dfn>/<x:dfn>downstream</x:dfn>
- <list>
- <t>
- Upstream and downstream describe the flow of a message: all
- messages flow from upstream to downstream.
- </t>
- </list>
-</t>
-<t>
- <iref item="inbound"/>
- <iref item="outbound"/>
- <x:dfn>inbound</x:dfn>/<x:dfn>outbound</x:dfn>
- <list>
- <t>
- Inbound and outbound refer to the request and response paths for
- messages: "inbound" means "traveling toward the origin server",
- and "outbound" means "traveling toward the user agent"
- </t>
- </list>
-</t>
</section>
-<section title="Overall Operation">
-<t>
- The HTTP protocol is a request/response protocol. A client sends a
- request to the server in the form of a request method, URI, and
- protocol version, followed by a MIME-like message containing request
- modifiers, client information, and possible body content over a
- connection with a server. The server responds with a status line,
- including the message's protocol version and a success or error code,
- followed by a MIME-like message containing server information, entity
- metainformation, and possible entity-body content. The relationship
- between HTTP and MIME is described in <xref target="differences.between.http.entities.and.rfc.2045.entities"/>.
-</t>
-<t>
- Most HTTP communication is initiated by a user agent and consists of
- a request to be applied to a resource on some origin server. In the
- simplest case, this may be accomplished via a single connection (v)
- between the user agent (UA) and the origin server (O).
-</t>
-<figure><artwork type="drawing">
- request chain ------------------------>
- UA -------------------v------------------- O
- <----------------------- response chain
-</artwork></figure>
-<t>
- A more complicated situation occurs when one or more intermediaries
- are present in the request/response chain. There are three common
- forms of intermediary: proxy, gateway, and tunnel. A proxy is a
- forwarding agent, receiving requests for a URI in its absolute form,
- rewriting all or part of the message, and forwarding the reformatted
- request toward the server identified by the URI. A gateway is a
- receiving agent, acting as a layer above some other server(s) and, if
- necessary, translating the requests to the underlying server's
- protocol. A tunnel acts as a relay point between two connections
- without changing the messages; tunnels are used when the
- communication needs to pass through an intermediary (such as a
- firewall) even when the intermediary cannot understand the contents
- of the messages.
-</t>
-<figure><artwork type="drawing">
- request chain -------------------------------------->
- UA -----v----- A -----v----- B -----v----- C -----v----- O
- <------------------------------------- response chain
-</artwork></figure>
-<t>
- The figure above shows three intermediaries (A, B, and C) between the
- user agent and origin server. A request or response message that
- travels the whole chain will pass through four separate connections.
- This distinction is important because some HTTP communication options
- may apply only to the connection with the nearest, non-tunnel
- neighbor, only to the end-points of the chain, or to all connections
- along the chain. Although the diagram is linear, each participant may
- be engaged in multiple, simultaneous communications. For example, B
- may be receiving requests from many clients other than A, and/or
- forwarding requests to servers other than C, at the same time that it
- is handling A's request.
-</t>
-<t>
- Any party to the communication which is not acting as a tunnel may
- employ an internal cache for handling requests. The effect of a cache
- is that the request/response chain is shortened if one of the
- participants along the chain has a cached response applicable to that
- request. The following illustrates the resulting chain if B has a
- cached copy of an earlier response from O (via C) for a request which
- has not been cached by UA or A.
-</t>
-<figure><artwork type="drawing">
- request chain ---------->
- UA -----v----- A -----v----- B - - - - - - C - - - - - - O
- <--------- response chain
-</artwork></figure>
-<t>
- Not all responses are usefully cacheable, and some requests may
- contain modifiers which place special requirements on cache behavior.
- HTTP requirements for cache behavior and cacheable responses are
- defined in <xref target="caching"/>.
-</t>
-<t>
- In fact, there are a wide variety of architectures and configurations
- of caches and proxies currently being experimented with or deployed
- across the World Wide Web. These systems include national hierarchies
- of proxy caches to save transoceanic bandwidth, systems that
- broadcast or multicast cache entries, organizations that distribute
- subsets of cached data via CD-ROM, and so on. HTTP systems are used
- in corporate intranets over high-bandwidth links, and for access via
- PDAs with low-power radio links and intermittent connectivity. The
- goal of HTTP/1.1 is to support the wide diversity of configurations
- already deployed while introducing protocol constructs that meet the
- needs of those who build web applications that require high
- reliability and, failing that, at least reliable indications of
- failure.
-</t>
-<t>
- HTTP communication usually takes place over TCP/IP connections. The
- default port is TCP 80 <xref target="RFC1700"/>, but other ports can be used. This does
- not preclude HTTP from being implemented on top of any other protocol
- on the Internet, or on other networks. HTTP only presumes a reliable
- transport; any protocol that provides such guarantees can be used;
- the mapping of the HTTP/1.1 request and response structures onto the
- transport data units of the protocol in question is outside the scope
- of this specification.
-</t>
+<section title="Delta Seconds" anchor="delta.seconds">
<t>
- In HTTP/1.0, most implementations used a new connection for each
- request/response exchange. In HTTP/1.1, a connection may be used for
- one or more request/response exchanges, although connections may be
- closed for a variety of reasons (see <xref target="persistent.connections"/>).
+ Some HTTP header fields allow a time value to be specified as an
+ integer number of seconds, represented in decimal, after the time
+ that the message was received.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
+ delta-seconds = 1*DIGIT
+</artwork></figure>
</section>
</section>
-<section title="Notational Conventions and Generic Grammar">
-
-<section title="Augmented BNF">
+<section title="Caching in HTTP" anchor="caching">
+<section title="Overview" anchor="caching.overview">
<t>
- All of the mechanisms specified in this document are described in
- both prose and an augmented Backus-Naur Form (BNF) similar to that
- used by RFC 822 <xref target="RFC822"/>. Implementors will need to be familiar with the
- notation in order to understand this specification. The augmented BNF
- includes the following constructs:
+ HTTP is typically used for distributed information systems, where
+ performance can be improved by the use of response caches. The
+ HTTP/1.1 protocol includes a number of elements intended to make
+ caching work as well as possible. Because these elements are
+ inextricable from other aspects of the protocol, and because they
+ interact with each other, it is useful to describe the basic caching
+ design of HTTP separately from the detailed descriptions of methods,
+ headers, response codes, etc.
</t>
<t>
- name = definition
- <list>
- <t>
- The name of a rule is simply the name itself (without any
- enclosing "<" and ">") and is separated from its definition by the
- equal "=" character. White space is only significant in that
- indentation of continuation lines is used to indicate a rule
- definition that spans more than one line. Certain basic rules are
- in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
- brackets are used within definitions whenever their presence will
- facilitate discerning the use of rule names.
- </t>
- </list>
+ Caching would be useless if it did not significantly improve
+ performance. The goal of caching in HTTP/1.1 is to eliminate the need
+ to send requests in many cases, and to eliminate the need to send
+ full responses in many other cases. The former reduces the number of
+ network round-trips required for many operations; we use an
+ "expiration" mechanism for this purpose (see <xref target="expiration.model"/>). The
+ latter reduces network bandwidth requirements; we use a "validation"
+ mechanism for this purpose (see <xref target="validation.model"/>).
</t>
<t>
- "literal"
- <list>
- <t>
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
- </t>
+ Requirements for performance, availability, and disconnected
+ operation require us to be able to relax the goal of semantic
+ transparency. The HTTP/1.1 protocol allows origin servers, caches,
+ and clients to explicitly reduce transparency when necessary.
+ However, because non-transparent operation may confuse non-expert
+ users, and might be incompatible with certain server applications
+ (such as those for ordering merchandise), the protocol requires that
+ transparency be relaxed
+ <list style="symbols">
+ <t>only by an explicit protocol-level request when relaxed by
+ client or origin server</t>
+
+ <t>only with an explicit warning to the end user when relaxed by
+ cache or client</t>
</list>
</t>
<t>
- rule1 | rule2
- <list>
- <t>
- Elements separated by a bar ("|") are alternatives, e.g., "yes |
- no" will accept yes or no.
- </t>
+ Therefore, the HTTP/1.1 protocol provides these important elements:
+ <list style="numbers">
+ <t>Protocol features that provide full semantic transparency when
+ this is required by all parties.</t>
+
+ <t>Protocol features that allow an origin server or user agent to
+ explicitly request and control non-transparent operation.</t>
+
+ <t>Protocol features that allow a cache to attach warnings to
+ responses that do not preserve the requested approximation of
+ semantic transparency.</t>
</list>
</t>
<t>
- (rule1 rule2)
- <list>
- <t>
- Elements enclosed in parentheses are treated as a single element.
- Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
- foo elem" and "elem bar elem".
- </t>
- </list>
+ A basic principle is that it must be possible for the clients to
+ detect any potential relaxation of semantic transparency.
+ <list><t>
+ <x:h>Note:</x:h> The server, cache, or client implementor might be faced with
+ design decisions not explicitly discussed in this specification.
+ If a decision might affect semantic transparency, the implementor
+ ought to err on the side of maintaining transparency unless a
+ careful and complete analysis shows significant benefits in
+ breaking transparency.
+ </t></list>
</t>
+
+<section title="Cache Correctness" anchor="cache.correctness">
<t>
- *rule
- <list>
- <t>
- The character "*" preceding an element indicates repetition. The
- full form is "<n>*<m>element" indicating at least <n> and at most
- <m> occurrences of element. Default values are 0 and infinity so
- that "*(element)" allows any number, including zero; "1*element"
- requires at least one; and "1*2element" allows one or two.
- </t>
+ A correct cache &MUST; respond to a request with the most up-to-date
+ response held by the cache that is appropriate to the request (see
+ sections <xref target="disambiguating.expiration.values" format="counter"/>,
+ <xref target="disambiguating.multiple.responses" format="counter"/>,
+ and <xref target="cache.replacement" format="counter"/>) which meets one of the following
+ conditions:
+ <list style="numbers">
+ <t>It has been checked for equivalence with what the origin server
+ would have returned by revalidating the response with the
+ origin server (<xref target="validation.model"/>);</t>
+
+ <t>It is "fresh enough" (see <xref target="expiration.model"/>). In the default case,
+ this means it meets the least restrictive freshness requirement
+ of the client, origin server, and cache (see <xref target="header.cache-control"/>); if
+ the origin server so specifies, it is the freshness requirement
+ of the origin server alone.
+
+ If a stored response is not "fresh enough" by the most
+ restrictive freshness requirement of both the client and the
+ origin server, in carefully considered circumstances the cache
+ &MAY; still return the response with the appropriate Warning
+ header (see section <xref target="exceptions.to.the.rules.and.warnings" format="counter"/>
+ and <xref target="header.warning" format="counter"/>), unless such a response
+ is prohibited (e.g., by a "no-store" cache-directive, or by a
+ "no-cache" cache-request-directive; see <xref target="header.cache-control"/>).</t>
+
+ <t>It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+ or error (4xx or 5xx) response message.</t>
</list>
</t>
<t>
- [rule]
- <list>
- <t>
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
- </t>
- </list>
+ If the cache can not communicate with the origin server, then a
+ correct cache &SHOULD; respond as above if the response can be
+ correctly served from the cache; if not it &MUST; return an error or
+ warning indicating that there was a communication failure.
</t>
<t>
- N rule
- <list>
- <t>
- Specific repetition: "<n>(element)" is equivalent to
- "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
- Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
- alphabetic characters.
- </t>
- </list>
+ If a cache receives a response (either an entire response, or a 304
+ (Not Modified) response) that it would normally forward to the
+ requesting client, and the received response is no longer fresh, the
+ cache &SHOULD; forward it to the requesting client without adding a new
+ Warning (but without removing any existing Warning headers). A cache
+ &SHOULD-NOT; attempt to revalidate a response simply because that
+ response became stale in transit; this might lead to an infinite
+ loop. A user agent that receives a stale response without a Warning
+ &MAY; display a warning indication to the user.
</t>
+</section>
+
+<section title="Warnings" anchor="warnings">
<t>
- #rule
- <list>
- <t>
- A construct "#" is defined, similar to "*", for defining lists of
- elements. The full form is "<n>#<m>element" indicating at least
- <n> and at most <m> elements, each separated by one or more commas
- (",") and &OPTIONAL; linear white space (LWS). This makes the usual
- form of lists very easy; a rule such as
- </t>
- <t>
- ( *LWS element *( *LWS "," *LWS element ))
- </t>
- <t>
- can be shown as
- </t>
- <t>
- 1#element
- </t>
- <t>
- Wherever this construct is used, null elements are allowed, but do
- not contribute to the count of elements present. That is,
- "(element), , (element) " is permitted, but counts as only two
- elements. Therefore, where at least one element is required, at
- least one non-null element &MUST; be present. Default values are 0
- and infinity so that "#element" allows any number, including zero;
- "1#element" requires at least one; and "1#2element" allows one or
- two.
- </t>
- </list>
+ Whenever a cache returns a response that is neither first-hand nor
+ "fresh enough" (in the sense of condition 2 in <xref target="cache.correctness"/>), it
+ &MUST; attach a warning to that effect, using a Warning general-header.
+ The Warning header and the currently defined warnings are described
+ in <xref target="header.warning"/>. The warning allows clients to take appropriate
+ action.
</t>
<t>
- ; comment
- <list>
- <t>
- A semi-colon, set off some distance to the right of rule text,
- starts a comment that continues to the end of line. This is a
- simple way of including useful notes in parallel with the
- specifications.
- </t>
- </list>
+ Warnings &MAY; be used for other purposes, both cache-related and
+ otherwise. The use of a warning, rather than an error status code,
+ distinguish these responses from true failures.
</t>
<t>
- implied *LWS
- <list>
- <t>
- The grammar described by this specification is word-based. Except
- where noted otherwise, linear white space (LWS) can be included
- between any two adjacent words (token or quoted-string), and
- between adjacent words and separators, without changing the
- interpretation of a field. At least one delimiter (LWS and/or
- separators) &MUST; exist between any two tokens (for the definition
- of "token" below), since they would otherwise be interpreted as a
- single token.
- </t>
- </list>
+ Warnings are assigned three digit warn-codes. The first digit
+ indicates whether the Warning &MUST; or &MUST-NOT; be deleted from a
+ stored cache entry after a successful revalidation:
</t>
-</section>
-
-<section title="Basic Rules" anchor="basic.rules">
-<x:anchor-alias value="OCTET"/>
-<x:anchor-alias value="CHAR"/>
-<x:anchor-alias value="UPALPHA"/>
-<x:anchor-alias value="LOALPHA"/>
-<x:anchor-alias value="ALPHA"/>
-<x:anchor-alias value="DIGIT"/>
-<x:anchor-alias value="CTL"/>
-<x:anchor-alias value="CR"/>
-<x:anchor-alias value="LF"/>
-<x:anchor-alias value="SP"/>
-<x:anchor-alias value="HT"/>
-<x:anchor-alias value="CRLF"/>
-<x:anchor-alias value="LWS"/>
-<x:anchor-alias value="TEXT"/>
-<x:anchor-alias value="HEX"/>
-<x:anchor-alias value="token"/>
-<x:anchor-alias value="separators"/>
-<x:anchor-alias value="comment"/>
-<x:anchor-alias value="ctext"/>
-<x:anchor-alias value="quoted-string"/>
-<x:anchor-alias value="qdtext"/>
-<x:anchor-alias value="quoted-pair"/>
-<t>
- The following rules are used throughout this specification to
- describe basic parsing constructs. The US-ASCII coded character set
- is defined by ANSI X3.4-1986 <xref target="USASCII"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="OCTET"/><iref primary="true" item="Grammar" subitem="CHAR"/><iref primary="true" item="Grammar" subitem="UPALPHA"/><iref primary="true" item="Grammar" subitem="LOALPHA"/><iref primary="true" item="Grammar" subitem="ALPHA"/><iref primary="true" item="Grammar" subitem="DIGIT"/><iref primary="true" item="Grammar" subitem="CTL"/><iref primary="true" item="Grammar" subitem="CR"/><iref primary="true" item="Grammar" subitem="LF"/><iref primary="true" item="Grammar" subitem="SP"/><iref primary="true" item="Grammar" subitem="HT"/>
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- UPALPHA = <any US-ASCII uppercase letter "A".."Z">
- LOALPHA = <any US-ASCII lowercase letter "a".."z">
- ALPHA = UPALPHA | LOALPHA
- DIGIT = <any US-ASCII digit "0".."9">
- CTL = <any US-ASCII control character
- (octets 0 - 31) and DEL (127)>
- CR = <US-ASCII CR, carriage return (13)>
- LF = <US-ASCII LF, linefeed (10)>
- SP = <US-ASCII SP, space (32)>
- HT = <US-ASCII HT, horizontal-tab (9)>
- <"> = <US-ASCII double-quote mark (34)>
-</artwork></figure>
<t>
- HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
- protocol elements except the entity-body (see <xref target="tolerant.applications"/> for
- tolerant applications). The end-of-line marker within an entity-body
- is defined by its associated media type, as described in <xref target="media.types"/>.
+ <list style="hanging">
+ <t hangText="1xx">Warnings that describe the freshness or revalidation status of
+ the response, and so &MUST; be deleted after a successful
+ revalidation. 1XX warn-codes &MAY; be generated by a cache only when
+ validating a cached entry. It &MUST-NOT; be generated by clients.</t>
+
+ <t hangText="2xx">Warnings that describe some aspect of the entity body or entity
+ headers that is not rectified by a revalidation (for example, a
+ lossy compression of the entity bodies) and which &MUST-NOT; be
+ deleted after a successful revalidation.</t>
+ </list>
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="CRLF"/>
- CRLF = CR LF
-</artwork></figure>
<t>
- HTTP/1.1 header field values can be folded onto multiple lines if the
- continuation line begins with a space or horizontal tab. All linear
- white space, including folding, has the same semantics as SP. A
- recipient &MAY; replace any linear white space with a single SP before
- interpreting the field value or forwarding the message downstream.
+ See <xref target="header.warning"/> for the definitions of the codes themselves.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/>
- LWS = [CRLF] 1*( SP | HT )
-</artwork></figure>
<t>
- The TEXT rule is only used for descriptive field contents and values
- that are not intended to be interpreted by the message parser. Words
- of *TEXT &MAY; contain characters from character sets other than ISO-8859-1
- <xref target="ISO-8859"/> only when encoded according to the rules of RFC 2047
- <xref target="RFC2047"/>.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TEXT"/>
- TEXT = <any OCTET except CTLs,
- but including LWS>
-</artwork></figure>
-<t>
- A CRLF is allowed in the definition of TEXT only as part of a header
- field continuation. It is expected that the folding LWS will be
- replaced with a single SP before interpretation of the TEXT value.
+ HTTP/1.0 caches will cache all Warnings in responses, without
+ deleting the ones in the first category. Warnings in responses that
+ are passed to HTTP/1.0 caches carry an extra warning-date field,
+ which prevents a future HTTP/1.1 recipient from believing an
+ erroneously cached Warning.
</t>
<t>
- Hexadecimal numeric characters are used in several protocol elements.
+ Warnings also carry a warning text. The text &MAY; be in any
+ appropriate natural language (perhaps based on the client's Accept
+ headers), and include an &OPTIONAL; indication of what character set is
+ used.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HEX"/>
- HEX = "A" | "B" | "C" | "D" | "E" | "F"
- | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
-</artwork></figure>
<t>
- Many HTTP/1.1 header field values consist of words separated by LWS
- or special characters. These special characters &MUST; be in a quoted
- string to be used within a parameter value (as defined in
- <xref target="transfer.codings"/>).
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="token"/><iref primary="true" item="Grammar" subitem="separators"/>
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@"
- | "," | ";" | ":" | "\" | <">
- | "/" | "[" | "]" | "?" | "="
- | "{" | "}" | SP | HT
-</artwork></figure>
-<t>
- Comments can be included in some HTTP header fields by surrounding
- the comment text with parentheses. Comments are only allowed in
- fields containing "comment" as part of their field value definition.
- In all other fields, parentheses are considered part of the field
- value.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="comment"/><iref primary="true" item="Grammar" subitem="ctext"/>
- comment = "(" *( ctext | quoted-pair | comment ) ")"
- ctext = <any TEXT excluding "(" and ")">
-</artwork></figure>
-<t>
- A string of text is parsed as a single word if it is quoted using
- double-quote marks.
+ Multiple warnings &MAY; be attached to a response (either by the origin
+ server or by a cache), including multiple warnings with the same code
+ number. For example, a server might provide the same warning with
+ texts in both English and Basque.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-string"/><iref primary="true" item="Grammar" subitem="qdtext"/>
- quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
- qdtext = <any TEXT except <">>
-</artwork></figure>
<t>
- The backslash character ("\") &MAY; be used as a single-character
- quoting mechanism only within quoted-string and comment constructs.
+ When multiple warnings are attached to a response, it might not be
+ practical or reasonable to display all of them to the user. This
+ version of HTTP does not specify strict priority rules for deciding
+ which warnings to display and in what order, but does suggest some
+ heuristics.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="quoted-pair"/>
- quoted-pair = "\" CHAR
-</artwork></figure>
-</section>
</section>
-<section title="Protocol Parameters">
-
-<section title="HTTP Version" anchor="http.version">
-<t>
- HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
- of the protocol. The protocol versioning policy is intended to allow
- the sender to indicate the format of a message and its capacity for
- understanding further HTTP communication, rather than the features
- obtained via that communication. No change is made to the version
- number for the addition of message components which do not affect
- communication behavior or which only add to extensible field values.
- The <minor> number is incremented when the changes made to the
- protocol add features which do not change the general message parsing
- algorithm, but which may add to the message semantics and imply
- additional capabilities of the sender. The <major> number is
- incremented when the format of a message within the protocol is
- changed. See RFC 2145 <xref target="RFC2145"/> for a fuller explanation.
-</t>
-<t>
- The version of an HTTP message is indicated by an HTTP-Version field
- in the first line of the message.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/>
- HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
-</artwork></figure>
+<section title="Cache-control Mechanisms">
<t>
- Note that the major and minor numbers &MUST; be treated as separate
- integers and that each &MAY; be incremented higher than a single digit.
- Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
- lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
- &MUST-NOT; be sent.
-</t>
-<t>
- An application that sends a request or response message that includes
- HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
- with this specification. Applications that are at least conditionally
- compliant with this specification &SHOULD; use an HTTP-Version of
- "HTTP/1.1" in their messages, and &MUST; do so for any message that is
- not compatible with HTTP/1.0. For more details on when to send
- specific HTTP-Version values, see RFC 2145 <xref target="RFC2145"/>.
-</t>
-<t>
- The HTTP version of an application is the highest HTTP version for
- which the application is at least conditionally compliant.
-</t>
-<t>
- Proxy and gateway applications need to be careful when forwarding
- messages in protocol versions different from that of the application.
- Since the protocol version indicates the protocol capability of the
- sender, a proxy/gateway &MUST-NOT; send a message with a version
- indicator which is greater than its actual version. If a higher
- version request is received, the proxy/gateway &MUST; either downgrade
- the request version, or respond with an error, or switch to tunnel
- behavior.
+ The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+ times and validators) are implicit directives to caches. In some
+ cases, a server or client might need to provide explicit directives
+ to the HTTP caches. We use the Cache-Control header for this purpose.
</t>
<t>
- Due to interoperability problems with HTTP/1.0 proxies discovered
- since the publication of RFC 2068 <xref target="RFC2068"/>, caching proxies MUST, gateways
- &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
- they support. The proxy/gateway's response to that request &MUST; be in
- the same major version as the request.
+ The Cache-Control header allows a client or server to transmit a
+ variety of directives in either requests or responses. These
+ directives typically override the default caching algorithms. As a
+ general rule, if there is any apparent conflict between header
+ values, the most restrictive interpretation is applied (that is, the
+ one that is most likely to preserve semantic transparency). However,
+ in some cases, cache-control directives are explicitly specified as
+ weakening the approximation of semantic transparency (for example,
+ "max-stale" or "public").
</t>
<t>
- <list>
- <t>
- <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
- of header fields required or forbidden by the versions involved.
- </t>
- </list>
+ The cache-control directives are described in detail in <xref target="header.cache-control"/>.
</t>
</section>
-<section title="Uniform Resource Identifiers" anchor="uri">
+<section title="Explicit User Agent Warnings">
<t>
- URIs have been known by many names: WWW addresses, Universal Document
- Identifiers, Universal Resource Identifiers <xref target="RFC1630"/>, and finally the
- combination of Uniform Resource Locators (URL) <xref target="RFC1738"/> and Names (URN)
- <xref target="RFC1737"/>. As far as HTTP is concerned, Uniform Resource Identifiers are
- simply formatted strings which identify--via name, location, or any
- other characteristic--a resource.
-</t>
-
-<section title="General Syntax" anchor="general.syntax">
-<t>
- URIs in HTTP can be represented in absolute form or relative to some
- known base URI <xref target="RFC1808"/>, depending upon the context of their use. The two
- forms are differentiated by the fact that absolute URIs always begin
- with a scheme name followed by a colon. For definitive information on
- URL syntax and semantics, see "Uniform Resource Identifiers (URI):
- Generic Syntax and Semantics," RFC 2396 <xref target="RFC2396"/> (which replaces RFCs
- 1738 <xref target="RFC1738"/> and RFC 1808 <xref target="RFC1808"/>). This specification adopts the
- definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
- "host","abs_path", "rel_path", and "authority" from that
- specification.
-</t>
-<t>
- The HTTP protocol does not place any a priori limit on the length of
- a URI. Servers &MUST; be able to handle the URI of any resource they
- serve, and &SHOULD; be able to handle URIs of unbounded length if they
- provide GET-based forms that could generate such URIs. A server
- &SHOULD; return 414 (Request-URI Too Long) status if a URI is longer
- than the server can handle (see <xref target="status.414"/>).
+ Many user agents make it possible for users to override the basic
+ caching mechanisms. For example, the user agent might allow the user
+ to specify that cached entities (even explicitly stale ones) are
+ never validated. Or the user agent might habitually add "Cache-Control:
+ max-stale=3600" to every request. The user agent &SHOULD-NOT;
+ default to either non-transparent behavior, or behavior that results
+ in abnormally ineffective caching, but &MAY; be explicitly configured
+ to do so by an explicit action of the user.
</t>
<t>
- <list>
- <t>
- <x:h>Note:</x:h> Servers ought to be cautious about depending on URI lengths
- above 255 bytes, because some older client or proxy
- implementations might not properly support these lengths.
- </t>
- </list>
+ If the user has overridden the basic caching mechanisms, the user
+ agent &SHOULD; explicitly indicate to the user whenever this results in
+ the display of information that might not meet the server's
+ transparency requirements (in particular, if the displayed entity is
+ known to be stale). Since the protocol normally allows the user agent
+ to determine if responses are stale or not, this indication need only
+ be displayed when this actually happens. The indication need not be a
+ dialog box; it could be an icon (for example, a picture of a rotting
+ fish) or some other indicator.
+</t>
+<t>
+ If the user has overridden the caching mechanisms in a way that would
+ abnormally reduce the effectiveness of caches, the user agent &SHOULD;
+ continually indicate this state to the user (for example, by a
+ display of a picture of currency in flames) so that the user does not
+ inadvertently consume excess resources or suffer from excessive
+ latency.
</t>
</section>
-<section title="http URL" anchor="http.url">
+<section title="Exceptions to the Rules and Warnings" anchor="exceptions.to.the.rules.and.warnings">
<t>
- The "http" scheme is used to locate network resources via the HTTP
- protocol. This section defines the scheme-specific syntax and
- semantics for http URLs.
+ In some cases, the operator of a cache &MAY; choose to configure it to
+ return stale responses even when not requested by clients. This
+ decision ought not be made lightly, but may be necessary for reasons
+ of availability or performance, especially when the cache is poorly
+ connected to the origin server. Whenever a cache returns a stale
+ response, it &MUST; mark it as such (using a Warning header) enabling
+ the client software to alert the user that there might be a potential
+ problem.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http_URL"/>
-http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
-</artwork></figure>
<t>
- If the port is empty or not given, port 80 is assumed. The semantics
- are that the identified resource is located at the server listening
- for TCP connections on that port of that host, and the Request-URI
- for the resource is abs_path (<xref target="request-uri"/>). The use of IP addresses
- in URLs &SHOULD; be avoided whenever possible (see RFC 1900 <xref target="RFC1900"/>). If
- the abs_path is not present in the URL, it &MUST; be given as "/" when
- used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
-
- receives a host name which is not a fully qualified domain name, it
- &MAY; add its domain to the host name it received. If a proxy receives
- a fully qualified domain name, the proxy &MUST-NOT; change the host
- name.
+ It also allows the user agent to take steps to obtain a first-hand or
+ fresh response. For this reason, a cache &SHOULD-NOT; return a stale
+ response if the client explicitly requests a first-hand or fresh one,
+ unless it is impossible to comply for technical or policy reasons.
</t>
</section>
-<section title="URI Comparison" anchor="uri.comparison">
-<t>
- When comparing two URIs to decide if they match or not, a client
- &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
- URIs, with these exceptions:
- <list style="symbols">
- <t>A port that is empty or not given is equivalent to the default
- port for that URI-reference;</t>
- <t>Comparisons of host names &MUST; be case-insensitive;</t>
- <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
- <t>An empty abs_path is equivalent to an abs_path of "/".</t>
- </list>
+<section title="Client-controlled Behavior">
+<t>
+ While the origin server (and to a lesser extent, intermediate caches,
+ by their contribution to the age of a response) are the primary
+ source of expiration information, in some cases the client might need
+ to control a cache's decision about whether to return a cached
+ response without validating it. Clients do this using several
+ directives of the Cache-Control header.
</t>
<t>
- Characters other than those in the "reserved" and "unsafe" sets (see
- RFC 2396 <xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding.
+ A client's request &MAY; specify the maximum age it is willing to
+ accept of an unvalidated response; specifying a value of zero forces
+ the cache(s) to revalidate all responses. A client &MAY; also specify
+ the minimum time remaining before a response expires. Both of these
+ options increase constraints on the behavior of caches, and so cannot
+ further relax the cache's approximation of semantic transparency.
</t>
<t>
- For example, the following three URIs are equivalent:
+ A client &MAY; also specify that it will accept stale responses, up to
+ some maximum amount of staleness. This loosens the constraints on the
+ caches, and so might violate the origin server's specified
+ constraints on semantic transparency, but might be necessary to
+ support disconnected operation, or high availability in the face of
+ poor connectivity.
</t>
-<figure><artwork type="example">
- http://abc.com:80/~smith/home.html
- http://ABC.com/%7Esmith/home.html
- http://ABC.com:/%7esmith/home.html
-</artwork></figure>
</section>
</section>
-<section title="Date/Time Formats">
+<section title="Expiration Model" anchor="expiration.model">
-<section title="Full Date" anchor="full.date">
+<section title="Server-Specified Expiration">
<t>
- HTTP applications have historically allowed three different formats
- for the representation of date/time stamps:
+ HTTP caching works best when caches can entirely avoid making
+ requests to the origin server. The primary mechanism for avoiding
+ requests is for an origin server to provide an explicit expiration
+ time in the future, indicating that a response &MAY; be used to satisfy
+ subsequent requests. In other words, a cache can return a fresh
+ response without first contacting the server.
</t>
-<figure><artwork type="example">
- Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
- Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
- Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
-</artwork></figure>
<t>
- The first format is preferred as an Internet standard and represents
- a fixed-length subset of that defined by RFC 1123 <xref target="RFC1123"/> (an update to
- RFC 822 <xref target="RFC822"/>). The second format is in common use, but is based on the
- obsolete RFC 850 <xref target="RFC1036"/> date format and lacks a four-digit year.
- HTTP/1.1 clients and servers that parse the date value &MUST; accept
- all three formats (for compatibility with HTTP/1.0), though they &MUST;
- only generate the RFC 1123 format for representing HTTP-date values
- in header fields. See <xref target="tolerant.applications"/> for further information.
-</t>
-<t><list><t>
- <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
- accepting date values that may have been sent by non-HTTP
- applications, as is sometimes the case when retrieving or posting
- messages via proxies/gateways to SMTP or NNTP.
-</t></list></t>
-<t>
- All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
- (GMT), without exception. For the purposes of HTTP, GMT is exactly
- equal to UTC (Coordinated Universal Time). This is indicated in the
- first two formats by the inclusion of "GMT" as the three-letter
- abbreviation for time zone, and &MUST; be assumed when reading the
- asctime format. HTTP-date is case sensitive and &MUST-NOT; include
- additional LWS beyond that specifically included as SP in the
- grammar.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="rfc850-date"/><iref primary="true" item="Grammar" subitem="asctime-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/><iref primary="true" item="Grammar" subitem="time"/><iref primary="true" item="Grammar" subitem="wkday"/><iref primary="true" item="Grammar" subitem="weekday"/><iref primary="true" item="Grammar" subitem="month"/>
- HTTP-date = rfc1123-date | rfc850-date | asctime-date
- rfc1123-date = wkday "," SP date1 SP time SP "GMT"
- rfc850-date = weekday "," SP date2 SP time SP "GMT"
- asctime-date = wkday SP date3 SP time SP 4DIGIT
- date1 = 2DIGIT SP month SP 4DIGIT
- ; day month year (e.g., 02 Jun 1982)
- date2 = 2DIGIT "-" month "-" 2DIGIT
- ; day-month-year (e.g., 02-Jun-82)
- date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
- ; month day (e.g., Jun 2)
- time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; 00:00:00 - 23:59:59
- wkday = "Mon" | "Tue" | "Wed"
- | "Thu" | "Fri" | "Sat" | "Sun"
- weekday = "Monday" | "Tuesday" | "Wednesday"
- | "Thursday" | "Friday" | "Saturday" | "Sunday"
- month = "Jan" | "Feb" | "Mar" | "Apr"
- | "May" | "Jun" | "Jul" | "Aug"
- | "Sep" | "Oct" | "Nov" | "Dec"
-</artwork></figure>
-<t>
- <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only
- to their usage within the protocol stream. Clients and servers are
- not required to use these formats for user presentation, request
- logging, etc.
+ Our expectation is that servers will assign future explicit
+ expiration times to responses in the belief that the entity is not
+ likely to change, in a semantically significant way, before the
+ expiration time is reached. This normally preserves semantic
+ transparency, as long as the server's expiration times are carefully
+ chosen.
</t>
-</section>
-
-<section title="Delta Seconds">
<t>
- Some HTTP header fields allow a time value to be specified as an
- integer number of seconds, represented in decimal, after the time
- that the message was received.
+ The expiration mechanism applies only to responses taken from a cache
+ and not to first-hand responses forwarded immediately to the
+ requesting client.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
- delta-seconds = 1*DIGIT
-</artwork></figure>
-</section>
-</section>
-
-<section title="Character Sets" anchor="character.sets">
<t>
- HTTP uses the same definition of the term "character set" as that
- described for MIME:
+ If an origin server wishes to force a semantically transparent cache
+ to validate every request, it &MAY; assign an explicit expiration time
+ in the past. This means that the response is always stale, and so the
+ cache &SHOULD; validate it before using it for subsequent requests. See
+ <xref target="cache.revalidation.and.reload.controls"/> for a more restrictive way to force revalidation.
</t>
<t>
- The term "character set" is used in this document to refer to a
- method used with one or more tables to convert a sequence of octets
- into a sequence of characters. Note that unconditional conversion in
- the other direction is not required, in that not all characters may
- be available in a given character set and a character set may provide
- more than one sequence of octets to represent a particular character.
- This definition is intended to allow various kinds of character
- encoding, from simple single-table mappings such as US-ASCII to
- complex table switching methods such as those that use ISO-2022's
- techniques. However, the definition associated with a MIME character
- set name &MUST; fully specify the mapping to be performed from octets
- to characters. In particular, use of external profiling information
- to determine the exact mapping is not permitted.
-</t>
-<t><list><t>
- <x:h>Note:</x:h> This use of the term "character set" is more commonly
- referred to as a "character encoding." However, since HTTP and
- MIME share the same registry, it is important that the terminology
- also be shared.
-</t></list></t>
-<t>
- HTTP character sets are identified by case-insensitive tokens. The
- complete set of tokens is defined by the IANA Character Set registry
- <xref target="RFC1700"/>.
+ If an origin server wishes to force any HTTP/1.1 cache, no matter how
+ it is configured, to validate every request, it &SHOULD; use the "must-revalidate"
+ cache-control directive (see <xref target="header.cache-control"/>).
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
- charset = token
-</artwork></figure>
<t>
- Although HTTP allows an arbitrary token to be used as a charset
- value, any token that has a predefined value within the IANA
- Character Set registry <xref target="RFC1700"/> &MUST; represent the character set defined
- by that registry. Applications &SHOULD; limit their use of character
- sets to those defined by the IANA registry.
+ Servers specify explicit expiration times using either the Expires
+ header, or the max-age directive of the Cache-Control header.
</t>
<t>
- Implementors should be aware of IETF character set requirements <xref target="RFC2279"/>
- <xref target="RFC2277"/>.
+ An expiration time cannot be used to force a user agent to refresh
+ its display or reload a resource; its semantics apply only to caching
+ mechanisms, and such mechanisms need only check a resource's
+ expiration status when a new request for that resource is initiated.
+ See <xref target="history.lists"/> for an explanation of the difference between caches
+ and history mechanisms.
</t>
+</section>
-<section title="Missing Charset" anchor="missing.charset">
-<t>
- Some HTTP/1.0 software has interpreted a Content-Type header without
- charset parameter incorrectly to mean "recipient should guess."
- Senders wishing to defeat this behavior &MAY; include a charset
- parameter even when the charset is ISO-8859-1 and &SHOULD; do so when
- it is known that it will not confuse the recipient.
-</t>
+<section title="Heuristic Expiration">
<t>
- Unfortunately, some older HTTP/1.0 clients did not deal properly with
- an explicit charset parameter. HTTP/1.1 recipients &MUST; respect the
- charset label provided by the sender; and those user agents that have
- a provision to "guess" a charset &MUST; use the charset from the
- content-type field if they support that charset, rather than the
- recipient's preference, when initially displaying a document. See
- <xref target="canonicalization.and.text.defaults"/>.
+ Since origin servers do not always provide explicit expiration times,
+ HTTP caches typically assign heuristic expiration times, employing
+ algorithms that use other header values (such as the Last-Modified
+ time) to estimate a plausible expiration time. The HTTP/1.1
+ specification does not provide specific algorithms, but does impose
+ worst-case constraints on their results. Since heuristic expiration
+ times might compromise semantic transparency, they ought to used
+ cautiously, and we encourage origin servers to provide explicit
+ expiration times as much as possible.
</t>
</section>
-</section>
-<section title="Content Codings" anchor="content.codings">
+<section title="Age Calculations" anchor="age.calculations">
<t>
- Content coding values indicate an encoding transformation that has
- been or can be applied to an entity. Content codings are primarily
- used to allow a document to be compressed or otherwise usefully
- transformed without losing the identity of its underlying media type
- and without loss of information. Frequently, the entity is stored in
- coded form, transmitted directly, and only decoded by the recipient.
+ In order to know if a cached entry is fresh, a cache needs to know if
+ its age exceeds its freshness lifetime. We discuss how to calculate
+ the latter in <xref target="expiration.calculations"/>; this section describes how to calculate
+ the age of a response or cache entry.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
- content-coding = token
-</artwork></figure>
<t>
- All content-coding values are case-insensitive. HTTP/1.1 uses
- content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
- Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
- describes the content-coding, what is more important is that it
- indicates what decoding mechanism will be required to remove the
- encoding.
+ In this discussion, we use the term "now" to mean "the current value
+ of the clock at the host performing the calculation." Hosts that use
+ HTTP, but especially hosts running origin servers and caches, &SHOULD;
+ use NTP <xref target="RFC1305"/> or some similar protocol to synchronize their clocks to
+ a globally accurate time standard.
</t>
<t>
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- content-coding value tokens. Initially, the registry contains the
- following tokens:
+ HTTP/1.1 requires origin servers to send a Date header, if possible,
+ with every response, giving the time at which the response was
+ generated (see &header-date;). We use the term "date_value" to denote
+ the value of the Date header, in a form appropriate for arithmetic
+ operations.
</t>
<t>
- gzip<iref item="gzip"/>
- <list>
- <t>
- An encoding format produced by the file compression program
- "gzip" (GNU zip) as described in RFC 1952 <xref target="RFC1952"/>. This format is a
- Lempel-Ziv coding (LZ77) with a 32 bit CRC.
- </t>
- </list>
-</t>
-<t>
- compress<iref item="compress"/>
- <list><t>
- The encoding format produced by the common UNIX file compression
- program "compress". This format is an adaptive Lempel-Ziv-Welch
- coding (LZW).
-</t><t>
- Use of program names for the identification of encoding formats
- is not desirable and is discouraged for future encodings. Their
- use here is representative of historical practice, not good
- design. For compatibility with previous implementations of HTTP,
- applications &SHOULD; consider "x-gzip" and "x-compress" to be
- equivalent to "gzip" and "compress" respectively.
- </t></list>
+ HTTP/1.1 uses the Age response-header to convey the estimated age of
+ the response message when obtained from a cache. The Age field value
+ is the cache's estimate of the amount of time since the response was
+ generated or revalidated by the origin server.
</t>
<t>
- deflate<iref item="deflate"/>
- <list><t>
- The "zlib" format defined in RFC 1950 <xref target="RFC1950"/> in combination with
- the "deflate" compression mechanism described in RFC 1951 <xref target="RFC1951"/>.
- </t></list>
+ In essence, the Age value is the sum of the time that the response
+ has been resident in each of the caches along the path from the
+ origin server, plus the amount of time it has been in transit along
+ network paths.
</t>
<t>
- identity<iref item="identity"/>
- <list><t>
- The default (identity) encoding; the use of no transformation
- whatsoever. This content-coding is used only in the Accept-Encoding
- header, and &SHOULD-NOT; be used in the Content-Encoding
- header.
- </t></list>
+ We use the term "age_value" to denote the value of the Age header, in
+ a form appropriate for arithmetic operations.
</t>
<t>
- New content-coding value tokens &SHOULD; be registered; to allow
- interoperability between clients and servers, specifications of the
- content coding algorithms needed to implement a new value &SHOULD; be
- publicly available and adequate for independent implementation, and
- conform to the purpose of content coding defined in this section.
-</t>
-</section>
+ A response's age can be calculated in two entirely independent ways:
+ <list style="numbers">
+ <t>now minus date_value, if the local clock is reasonably well
+ synchronized to the origin server's clock. If the result is
+ negative, the result is replaced by zero.</t>
-<section title="Transfer Codings" anchor="transfer.codings">
-<t>
- Transfer-coding values are used to indicate an encoding
- transformation that has been, can be, or may need to be applied to an
- entity-body in order to ensure "safe transport" through the network.
- This differs from a content coding in that the transfer-coding is a
- property of the message, not of the original entity.
+ <t>age_value, if all of the caches along the response path
+ implement HTTP/1.1.</t>
+ </list>
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/>
- transfer-coding = "chunked" | transfer-extension
- transfer-extension = token *( ";" parameter )
-</artwork></figure>
<t>
- Parameters are in the form of attribute/value pairs.
+ Given that we have two independent ways to compute the age of a
+ response when it is received, we can combine these as
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>
- parameter = attribute "=" value
- attribute = token
- value = token | quoted-string
+<figure><artwork type="code">
+ corrected_received_age = max(now - date_value, age_value)
</artwork></figure>
<t>
- All transfer-coding values are case-insensitive. HTTP/1.1 uses
- transfer-coding values in the TE header field (<xref target="header.te"/>) and in
- the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
-</t>
-<t>
- Whenever a transfer-coding is applied to a message-body, the set of
- transfer-codings &MUST; include "chunked", unless the message is
- terminated by closing the connection. When the "chunked" transfer-coding
- is used, it &MUST; be the last transfer-coding applied to the
- message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
- than once to a message-body. These rules allow the recipient to
- determine the transfer-length of the message (<xref target="message.length"/>).
-</t>
-<t>
- Transfer-codings are analogous to the Content-Transfer-Encoding
- values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of
- binary data over a 7-bit transport service. However, safe transport
- has a different focus for an 8bit-clean transfer protocol. In HTTP,
- the only unsafe characteristic of message-bodies is the difficulty in
- determining the exact body length (<xref target="entity.length"/>), or the desire to
- encrypt data over a shared transport.
-</t>
-<t>
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- transfer-coding value tokens. Initially, the registry contains the
- following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>), "identity" (section
- 3.6.2), "gzip" (<xref target="content.codings"/>), "compress" (<xref target="content.codings"/>), and "deflate"
- (<xref target="content.codings"/>).
-</t>
-<t>
- New transfer-coding value tokens &SHOULD; be registered in the same way
- as new content-coding value tokens (<xref target="content.codings"/>).
-</t>
-<t>
- A server which receives an entity-body with a transfer-coding it does
- not understand &SHOULD; return 501 (Unimplemented), and close the
- connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
- client.
-</t>
-
-<section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding">
-<t>
- The chunked encoding modifies the body of a message in order to
- transfer it as a series of chunks, each with its own size indicator,
- followed by an &OPTIONAL; trailer containing entity-header fields. This
- allows dynamically produced content to be transferred along with the
- information necessary for the recipient to verify that it has
- received the full message.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-extension"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer"/>
- Chunked-Body = *chunk
- last-chunk
- trailer
- CRLF
-
- chunk = chunk-size [ chunk-extension ] CRLF
- chunk-data CRLF
- chunk-size = 1*HEX
- last-chunk = 1*("0") [ chunk-extension ] CRLF
-
- chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
- chunk-ext-name = token
- chunk-ext-val = token | quoted-string
- chunk-data = chunk-size(OCTET)
- trailer = *(entity-header CRLF)
-</artwork></figure>
+ and as long as we have either nearly synchronized clocks or all-HTTP/1.1
+ paths, one gets a reliable (conservative) result.
+</t>
<t>
- The chunk-size field is a string of hex digits indicating the size of
- the chunk. The chunked encoding is ended by any chunk whose size is
- zero, followed by the trailer, which is terminated by an empty line.
+ Because of network-imposed delays, some significant interval might
+ pass between the time that a server generates a response and the time
+ it is received at the next outbound cache or client. If uncorrected,
+ this delay could result in improperly low ages.
</t>
<t>
- The trailer allows the sender to include additional HTTP header
- fields at the end of the message. The Trailer header field can be
- used to indicate which header fields are included in a trailer (see
- <xref target="header.trailer"/>).
+ Because the request that resulted in the returned Age value must have
+ been initiated prior to that Age value's generation, we can correct
+ for delays imposed by the network by recording the time at which the
+ request was initiated. Then, when an Age value is received, it &MUST;
+ be interpreted relative to the time the request was initiated, not
+ the time that the response was received. This algorithm results in
+ conservative behavior no matter how much delay is experienced. So, we
+ compute:
</t>
+<figure><artwork type="code">
+ corrected_initial_age = corrected_received_age
+ + (now - request_time)
+</artwork></figure>
<t>
- A server using chunked transfer-coding in a response &MUST-NOT; use the
- trailer for any header fields unless at least one of the following is
- true:
- <list style="numbers">
- <t>the request included a TE header field that indicates "trailers" is
- acceptable in the transfer-coding of the response, as described in
- <xref target="header.te"/>; or,</t>
-
- <t>the server is the origin server for the response, the trailer
- fields consist entirely of optional metadata, and the recipient
- could use the message (in a manner acceptable to the origin server)
- without receiving this metadata. In other words, the origin server
- is willing to accept the possibility that the trailer fields might
- be silently discarded along the path to the client.</t>
- </list>
+ where "request_time" is the time (according to the local clock) when
+ the request that elicited this response was sent.
</t>
<t>
- This requirement prevents an interoperability failure when the
- message is being received by an HTTP/1.1 (or later) proxy and
- forwarded to an HTTP/1.0 recipient. It avoids a situation where
- compliance with the protocol would have necessitated a possibly
- infinite buffer on the proxy.
+ Summary of age calculation algorithm, when a cache receives a
+ response:
</t>
+<figure><artwork type="code">
+ /*
+ * age_value
+ * is the value of Age: header received by the cache with
+ * this response.
+ * date_value
+ * is the value of the origin server's Date: header
+ * request_time
+ * is the (local) time when the cache made the request
+ * that resulted in this cached response
+ * response_time
+ * is the (local) time when the cache received the
+ * response
+ * now
+ * is the current (local) time
+ */
+
+ apparent_age = max(0, response_time - date_value);
+ corrected_received_age = max(apparent_age, age_value);
+ response_delay = response_time - request_time;
+ corrected_initial_age = corrected_received_age + response_delay;
+ resident_time = now - response_time;
+ current_age = corrected_initial_age + resident_time;
+</artwork></figure>
<t>
- An example process for decoding a Chunked-Body is presented in
- <xref target="introduction.of.transfer-encoding"/>.
+ The current_age of a cache entry is calculated by adding the amount
+ of time (in seconds) since the cache entry was last validated by the
+ origin server to the corrected_initial_age. When a response is
+ generated from a cache entry, the cache &MUST; include a single Age
+ header field in the response with a value equal to the cache entry's
+ current_age.
</t>
<t>
- All HTTP/1.1 applications &MUST; be able to receive and decode the
- "chunked" transfer-coding, and &MUST; ignore chunk-extension extensions
- they do not understand.
+ The presence of an Age header field in a response implies that a
+ response is not first-hand. However, the converse is not true, since
+ the lack of an Age header field in a response does not imply that the
+ response is first-hand unless all caches along the request path are
+ compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
+ the Age header field).
</t>
</section>
-</section>
-<section title="Media Types" anchor="media.types">
+<section title="Expiration Calculations" anchor="expiration.calculations">
<t>
- HTTP uses Internet Media Types <xref target="RFC1590"/> in the Content-Type (<xref target="header.content-type"/>)
- and Accept (<xref target="header.accept"/>) header fields in order to provide
- open and extensible data typing and type negotiation.
+ In order to decide whether a response is fresh or stale, we need to
+ compare its freshness lifetime to its age. The age is calculated as
+ described in <xref target="age.calculations"/>; this section describes how to calculate
+ the freshness lifetime, and to determine if a response has expired.
+ In the discussion below, the values can be represented in any form
+ appropriate for arithmetic operations.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
- media-type = type "/" subtype *( ";" parameter )
- type = token
- subtype = token
-</artwork></figure>
<t>
- Parameters &MAY; follow the type/subtype in the form of attribute/value
- pairs (as defined in <xref target="transfer.codings"/>).
+ We use the term "expires_value" to denote the value of the Expires
+ header. We use the term "max_age_value" to denote an appropriate
+ value of the number of seconds carried by the "max-age" directive of
+ the Cache-Control header in a response (see <xref target="modifications.of.the.basic.expiration.mechanism"/>).
</t>
<t>
- The type, subtype, and parameter attribute names are case-insensitive.
- Parameter values might or might not be case-sensitive,
- depending on the semantics of the parameter name. Linear white space
- (LWS) &MUST-NOT; be used between the type and subtype, nor between an
- attribute and its value. The presence or absence of a parameter might
- be significant to the processing of a media-type, depending on its
- definition within the media type registry.
-</t>
-<t>
- Note that some older HTTP applications do not recognize media type
- parameters. When sending data to older HTTP applications,
- implementations &SHOULD; only use media type parameters when they are
- required by that type/subtype definition.
-</t>
-<t>
- Media-type values are registered with the Internet Assigned Number
- Authority (IANA <xref target="RFC1700"/>). The media type registration process is
- outlined in RFC 1590 <xref target="RFC1590"/>. Use of non-registered media types is
- discouraged.
-</t>
-
-<section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">
-<t>
- Internet media types are registered with a canonical form. An
- entity-body transferred via HTTP messages &MUST; be represented in the
- appropriate canonical form prior to its transmission except for
- "text" types, as defined in the next paragraph.
-</t>
-<t>
- When in canonical form, media subtypes of the "text" type use CRLF as
- the text line break. HTTP relaxes this requirement and allows the
- transport of text media with plain CR or LF alone representing a line
- break when it is done consistently for an entire entity-body. HTTP
- applications &MUST; accept CRLF, bare CR, and bare LF as being
- representative of a line break in text media received via HTTP. In
- addition, if the text is represented in a character set that does not
- use octets 13 and 10 for CR and LF respectively, as is the case for
- some multi-byte character sets, HTTP allows the use of whatever octet
- sequences are defined by that character set to represent the
- equivalent of CR and LF for line breaks. This flexibility regarding
- line breaks applies only to text media in the entity-body; a bare CR
- or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control
- structures (such as header fields and multipart boundaries).
-</t>
-<t>
- If an entity-body is encoded with a content-coding, the underlying
- data &MUST; be in a form defined above prior to being encoded.
-</t>
-<t>
- The "charset" parameter is used with some media types to define the
- character set (<xref target="character.sets"/>) of the data. When no explicit charset
- parameter is provided by the sender, media subtypes of the "text"
- type are defined to have a default charset value of "ISO-8859-1" when
- received via HTTP. Data in character sets other than "ISO-8859-1" or
- its subsets &MUST; be labeled with an appropriate charset value. See
- <xref target="missing.charset"/> for compatibility problems.
-</t>
-</section>
-
-<section title="Multipart Types" anchor="multipart.types">
-<t>
- MIME provides for a number of "multipart" types -- encapsulations of
- one or more entities within a single message-body. All multipart
- types share a common syntax, as defined in section <xref target="RFC2046" x:sec="5.1.1" x:fmt="number"/> of RFC 2046
- <xref target="RFC2046"/>, and &MUST; include a boundary parameter as part of the media type
- value. The message body is itself a protocol element and &MUST;
- therefore use only CRLF to represent line breaks between body-parts.
- Unlike in RFC 2046, the epilogue of any multipart message &MUST; be
- empty; HTTP applications &MUST-NOT; transmit the epilogue (even if the
- original multipart contains an epilogue). These restrictions exist in
- order to preserve the self-delimiting nature of a multipart message-body,
- wherein the "end" of the message-body is indicated by the
- ending multipart boundary.
-</t>
-<t>
- In general, HTTP treats a multipart message-body no differently than
- any other media type: strictly as payload. The one exception is the
- "multipart/byteranges" type (<xref target="internet.media.type.multipart.byteranges"/>) when it appears in a 206
- (Partial Content) response, which will be interpreted by some HTTP
- caching mechanisms as described in sections <xref target="combining.byte.ranges" format="counter"/>
- and <xref target="header.content-range" format="counter"/>. In all
- other cases, an HTTP user agent &SHOULD; follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- The MIME header fields within each body-part of a multipart message-body
- do not have any significance to HTTP beyond that defined by
- their MIME semantics.
-</t>
-<t>
- In general, an HTTP user agent &SHOULD; follow the same or similar
- behavior as a MIME user agent would upon receipt of a multipart type.
- If an application receives an unrecognized multipart subtype, the
- application &MUST; treat it as being equivalent to "multipart/mixed".
-</t>
-<t><list><t>
- <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
- for carrying form data suitable for processing via the POST
- request method, as described in RFC 1867 <xref target="RFC1867"/>.
-</t></list></t>
-</section>
-</section>
-
-<section title="Product Tokens" anchor="product.tokens">
-<t>
- Product tokens are used to allow communicating applications to
- identify themselves by software name and version. Most fields using
- product tokens also allow sub-products which form a significant part
- of the application to be listed, separated by white space. By
- convention, the products are listed in order of their significance
- for identifying the application.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
- product = token ["/" product-version]
- product-version = token
-</artwork></figure>
-<t>
- Examples:
+ The max-age directive takes priority over Expires, so if max-age is
+ present in a response, the calculation is simply:
</t>
-<figure><artwork type="example">
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
- Server: Apache/0.8.4
+<figure><artwork type="code">
+ freshness_lifetime = max_age_value
</artwork></figure>
<t>
- Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
- used for advertising or other non-essential information. Although any
- token character &MAY; appear in a product-version, this token &SHOULD;
- only be used for a version identifier (i.e., successive versions of
- the same product &SHOULD; only differ in the product-version portion of
- the product value).
+ Otherwise, if Expires is present in the response, the calculation is:
</t>
-</section>
-
-<section title="Quality Values" anchor="quality.values">
-<t>
- HTTP content negotiation (<xref target="content.negotiation"/>) uses short "floating point"
- numbers to indicate the relative importance ("weight") of various
- negotiable parameters. A weight is normalized to a real number in
- the range 0 through 1, where 0 is the minimum and 1 the maximum
- value. If a parameter has a quality value of 0, then content with
- this parameter is `not acceptable' for the client. HTTP/1.1
- applications &MUST-NOT; generate more than three digits after the
- decimal point. User configuration of these values &SHOULD; also be
- limited in this fashion.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="qvalue"/>
- qvalue = ( "0" [ "." 0*3DIGIT ] )
- | ( "1" [ "." 0*3("0") ] )
+<figure><artwork type="code">
+ freshness_lifetime = expires_value - date_value
</artwork></figure>
<t>
- "Quality values" is a misnomer, since these values merely represent
- relative degradation in desired quality.
+ Note that neither of these calculations is vulnerable to clock skew,
+ since all of the information comes from the origin server.
</t>
-</section>
-
-<section title="Language Tags" anchor="language.tags">
<t>
- A language tag identifies a natural language spoken, written, or
- otherwise conveyed by human beings for communication of information
- to other human beings. Computer languages are explicitly excluded.
- HTTP uses language tags within the Accept-Language and Content-Language
- fields.
+ If none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage
+ (see <xref target="modifications.of.the.basic.expiration.mechanism"/>) appears in the response, and the response
+ does not include other restrictions on caching, the cache &MAY; compute
+ a freshness lifetime using a heuristic. The cache &MUST; attach Warning
+ 113 to any response whose age is more than 24 hours if such warning
+ has not already been added.
</t>
<t>
- The syntax and registry of HTTP language tags is the same as that
- defined by RFC 1766 <xref target="RFC1766"/>. In summary, a language tag is composed of 1
- or more parts: A primary language tag and a possibly empty series of
- subtags:
+ Also, if the response does have a Last-Modified time, the heuristic
+ expiration value &SHOULD; be no more than some fraction of the interval
+ since that time. A typical setting of this fraction might be 10%.
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/><iref primary="true" item="Grammar" subitem="primary-tag"/><iref primary="true" item="Grammar" subitem="subtag"/>
- language-tag = primary-tag *( "-" subtag )
- primary-tag = 1*8ALPHA
- subtag = 1*8ALPHA
-</artwork></figure>
<t>
- White space is not allowed within the tag and all tags are case-insensitive.
- The name space of language tags is administered by the
- IANA. Example tags include:
+ The calculation to determine if a response has expired is quite
+ simple:
</t>
-<figure><artwork type="example">
- en, en-US, en-cockney, i-cherokee, x-pig-latin
+<figure><artwork type="code">
+ response_is_fresh = (freshness_lifetime > current_age)
[... 10949 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org