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 [5/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/p4-conditional.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml?rev=583020&r1=583019&r2=583020&view=diff
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/p4-conditional.xml (original)
+++ labs/webarch/trunk/http/draft-fielding-http/p4-conditional.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,10 @@
<!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 header-if-range "[Part 5]">
+ <!ENTITY header-range "[Part 5]">
+ <!ENTITY header-vary "[Part 6]">
]>
<?rfc toc="yes" ?>
<?rfc symrefs="no" ?>
@@ -20,11 +24,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-p4-conditional-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 4">HTTP/1.1, part 4: Conditional Requests</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
@@ -126,11229 +131,698 @@
</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 4 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 request header fields for
+ indicating conditional requests and the rules for constructing responses
+ to those requests.
</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 conditional
+ request messages based on time stamps and entity-tags. Right now it
+ only includes the extracted relevant sections of <xref target="RFC2616">RFC 2616</xref>
+ without edit.
</t>
</section>
-<section title="Terminology">
-<t>
- This specification uses a number of terms to refer to the roles
- 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>
+<section title="Entity Tags" anchor="entity.tags">
<t>
- <iref item="request"/>
- <x:dfn>request</x:dfn>
- <list>
- <t>
- An HTTP request message, as defined in <xref target="request"/>.
- </t>
- </list>
+ Entity tags are used for comparing two or more entities from the same
+ requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
+ If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
+ If-Range (&header-if-range;) header fields. The definition of how they
+ are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
+ entity tag consists of an opaque quoted string, possibly prefixed by
+ a weakness indicator.
</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/>
+ entity-tag = [ weak ] opaque-tag
+ weak = "W/"
+ opaque-tag = quoted-string
+</artwork></figure>
<t>
- <iref item="response"/>
- <x:dfn>response</x:dfn>
- <list>
- <t>
- An HTTP response message, as defined in <xref target="response"/>.
- </t>
- </list>
+ A "strong entity tag" &MAY; be shared by two entities of a resource
+ only if they are equivalent by octet equality.
</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>
+ A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by
+ two entities of a resource only if the entities are equivalent and
+ could be substituted for each other with no significant change in
+ semantics. A weak entity tag can only be used for weak comparison.
</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>
+ An entity tag &MUST; be unique across all versions of all entities
+ associated with a particular resource. A given entity tag value &MAY;
+ be used for entities obtained by requests on different URIs. The use
+ of the same entity tag value in conjunction with entities obtained by
+ requests on different URIs does not imply the equivalence of those
+ entities.
</t>
+</section>
+
+<section title="Weak and Strong Validators" anchor="weak.and.strong.validators">
<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>
+ Since both origin servers and caches will compare two validators to
+ decide if they represent the same or different entities, one normally
+ would expect that if the entity (the entity-body or any entity-headers)
+ changes in any way, then the associated validator would
+ change as well. If this is true, then we call this validator a
+ "strong validator."
</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>
+ However, there might be cases when a server prefers to change the
+ validator only on semantically significant changes, and not when
+ insignificant aspects of the entity change. A validator that does not
+ always change when the resource changes is a "weak validator."
</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>
+ Entity tags are normally "strong validators," but the protocol
+ provides a mechanism to tag an entity tag as "weak." One can think of
+ a strong validator as one that changes whenever the bits of an entity
+ changes, while a weak value changes whenever the meaning of an entity
+ changes. Alternatively, one can think of a strong validator as part
+ of an identifier for a specific entity, while a weak validator is
+ part of an identifier for a set of semantically equivalent entities.
+ <list><t>
+ <x:h>Note:</x:h> One example of a strong validator is an integer that is
+ incremented in stable storage every time an entity is changed.
+ </t><t>
+ An entity's modification time, if represented with one-second
+ resolution, could be a weak validator, since it is possible that
+ the resource might be modified twice during a single second.
+ </t><t>
+ Support for weak validators is optional. However, weak validators
+ allow for more efficient caching of equivalent objects; for
+ example, a hit counter on a site is probably good enough if it is
+ updated every few days or weeks, and any value during that period
+ is likely "good enough" to be equivalent.
+ </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>
+ A "use" of a validator is either when a client generates a request
+ and includes the validator in a validating header field, or when a
+ server compares two validators.
</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>
+ Strong validators are usable in any context. Weak validators are only
+ usable in contexts that do not depend on exact equality of an entity.
+ For example, either kind is usable for a conditional GET of a full
+ entity. However, only a strong validator is usable for a sub-range
+ retrieval, since otherwise the client might end up with an internally
+ inconsistent entity.
</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>
+ Clients &MAY; issue simple (non-subrange) GET requests with either weak
+ validators or strong validators. Clients &MUST-NOT; use weak validators
+ in other forms of request.
</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>
+ The only function that the HTTP/1.1 protocol defines on validators is
+ comparison. There are two validator comparison functions, depending
+ on whether the comparison context allows the use of weak validators
+ or not:
+ <list style="symbols">
+ <t>The strong comparison function: in order to be considered equal,
+ both validators &MUST; be identical in every way, and both &MUST-NOT;
+ be weak.</t>
+ <t>The weak comparison function: in order to be considered equal,
+ both validators &MUST; be identical in every way, but either or
+ both of them &MAY; be tagged as "weak" without affecting the
+ result.</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>
+ An entity tag is strong unless it is explicitly tagged as weak.
+ <xref target="entity.tags"/> gives the syntax for entity tags.
</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>
+ A Last-Modified time, when used as a validator in a request, is
+ implicitly weak unless it is possible to deduce that it is strong,
+ using the following rules:
+ <list style="symbols">
+ <t>The validator is being compared by an origin server to the
+ actual current validator for the entity and,</t>
+ <t>That origin server reliably knows that the associated entity did
+ not change twice during the second covered by the presented
+ validator.</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>
+ or
+ <list style="symbols">
+ <t>The validator is about to be used by a client in an If-Modified-Since
+ or If-Unmodified-Since header, because the client
+ has a cache entry for the associated entity, and</t>
+ <t>That cache entry includes a Date value, which gives the time
+ when the origin server sent the original response, and</t>
+ <t>The presented Last-Modified time is at least 60 seconds before
+ the Date value.</t>
</list>
</t>
<t>
- <iref item="cache"/>
- <x:dfn>cache</x:dfn>
- <list>
- <t>
- A program's local store of response messages and the subsystem
- that controls its message storage, retrieval, and deletion. A
- cache stores cacheable responses in order to reduce the response
- time and network bandwidth consumption on future, equivalent
- requests. Any client or server may include a cache, though a cache
- cannot be used by a server that is acting as a tunnel.
- </t>
+ or
+ <list style="symbols">
+ <t>The validator is being compared by an intermediate cache to the
+ validator stored in its cache entry for the entity, and</t>
+ <t>That cache entry includes a Date value, which gives the time
+ when the origin server sent the original response, and</t>
+ <t>The presented Last-Modified time is at least 60 seconds before
+ the Date value.</t>
</list>
</t>
<t>
- <iref item="cacheable"/>
- <x:dfn>cacheable</x:dfn>
- <list>
- <t>
- A response is cacheable if a cache is allowed to store a copy of
- the response message for use in answering subsequent requests. The
- rules for determining the cacheability of HTTP responses are
- defined in <xref target="caching"/>. Even if a resource is cacheable, there may
- be additional constraints on whether a cache can use the cached
- copy for a particular request.
- </t>
- </list>
+ This method relies on the fact that if two different responses were
+ sent by the origin server during the same second, but both had the
+ same Last-Modified time, then at least one of those responses would
+ have a Date value equal to its Last-Modified time. The arbitrary 60-second
+ limit guards against the possibility that the Date and Last-Modified
+ values are generated from different clocks, or at somewhat
+ different times during the preparation of the response. An
+ implementation &MAY; use a value larger than 60 seconds, if it is
+ believed that 60 seconds is too short.
</t>
<t>
- <iref item="first-hand"/>
- <x:dfn>first-hand</x:dfn>
- <list>
- <t>
- A response is first-hand if it comes directly and without
- unnecessary delay from the origin server, perhaps via one or more
- proxies. A response is also first-hand if its validity has just
- been checked directly with the origin server.
- </t>
- </list>
+ If a client wishes to perform a sub-range retrieval on a value for
+ which it has only a Last-Modified time and no opaque validator, it
+ &MAY; do this only if the Last-Modified time is strong in the sense
+ described here.
</t>
<t>
- <iref item="explicit expiration time"/>
- <x:dfn>explicit expiration time</x:dfn>
- <list>
- <t>
- The time at which the origin server intends that an entity should
- no longer be returned by a cache without further validation.
- </t>
- </list>
+ A cache or origin server receiving a conditional request, other than
+ a full-body GET request, &MUST; use the strong comparison function to
+ evaluate the condition.
</t>
<t>
- <iref item="heuristic expiration time"/>
- <x:dfn>heuristic expiration time</x:dfn>
- <list>
- <t>
- An expiration time assigned by a cache when no explicit expiration
- time is available.
- </t>
- </list>
+ These rules allow HTTP/1.1 caches and clients to safely perform sub-range
+ retrievals on values that have been obtained from HTTP/1.0
+ servers.
</t>
+</section>
+
+<section title="Rules for When to Use Entity Tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">
<t>
- <iref item="age"/>
- <x:dfn>age</x:dfn>
- <list>
- <t>
- The age of a response is the time since it was sent by, or
- successfully validated with, the origin server.
- </t>
- </list>
+ We adopt a set of rules and recommendations for origin servers,
+ clients, and caches regarding when various validator types ought to
+ be used, and for what purposes.
</t>
<t>
- <iref item="freshness lifetime"/>
- <x:dfn>freshness lifetime</x:dfn>
- <list>
- <t>
- The length of time between the generation of a response and its
- expiration time.
- </t>
+ HTTP/1.1 origin servers:
+ <list style="symbols">
+ <t>&SHOULD; send an entity tag validator unless it is not feasible to
+ generate one.</t>
+
+ <t>&MAY; send a weak entity tag instead of a strong entity tag, if
+ performance considerations support the use of weak entity tags,
+ or if it is unfeasible to send a strong entity tag.</t>
+
+ <t>&SHOULD; send a Last-Modified value if it is feasible to send one,
+ unless the risk of a breakdown in semantic transparency that
+ could result from using this date in an If-Modified-Since header
+ would lead to serious problems.</t>
</list>
</t>
<t>
- <iref item="fresh"/>
- <x:dfn>fresh</x:dfn>
- <list>
- <t>
- A response is fresh if its age has not yet exceeded its freshness
- lifetime.
- </t>
- </list>
+ In other words, the preferred behavior for an HTTP/1.1 origin server
+ is to send both a strong entity tag and a Last-Modified value.
</t>
<t>
- <iref item="stale"/>
- <x:dfn>stale</x:dfn>
- <list>
- <t>
- A response is stale if its age has passed its freshness lifetime.
- </t>
- </list>
+ In order to be legal, a strong entity tag &MUST; change whenever the
+ associated entity value changes in any way. A weak entity tag &SHOULD;
+ change whenever the associated entity changes in a semantically
+ significant way.
+ <list><t>
+ <x:h>Note:</x:h> in order to provide semantically transparent caching, an
+ origin server must avoid reusing a specific strong entity tag
+ value for two different entities, or reusing a specific weak
+ entity tag value for two semantically different entities. Cache
+ entries might persist for arbitrarily long periods, regardless of
+ expiration times, so it might be inappropriate to expect that a
+ cache will never again attempt to validate an entry using a
+ validator that it obtained at some point in the past.
+ </t></list>
</t>
<t>
- <iref item="semantically transparent"/>
- <x:dfn>semantically transparent</x:dfn>
- <list>
- <t>
- A cache behaves in a "semantically transparent" manner, with
- respect to a particular response, when its use affects neither the
- requesting client nor the origin server, except to improve
- performance. When a cache is semantically transparent, the client
- receives exactly the same response (except for hop-by-hop headers)
- that it would have received had its request been handled directly
- by the origin server.
- </t>
+ HTTP/1.1 clients:
+ <list style="symbols">
+ <t>If an entity tag has been provided by the origin server, &MUST;
+ use that entity tag in any cache-conditional request (using If-Match
+ or If-None-Match).</t>
+
+ <t>If only a Last-Modified value has been provided by the origin
+ server, &SHOULD; use that value in non-subrange cache-conditional
+ requests (using If-Modified-Since).</t>
+
+ <t>If only a Last-Modified value has been provided by an HTTP/1.0
+ origin server, &MAY; use that value in subrange cache-conditional
+ requests (using If-Unmodified-Since:). The user agent &SHOULD;
+ provide a way to disable this, in case of difficulty.</t>
+
+ <t>If both an entity tag and a Last-Modified value have been
+ provided by the origin server, &SHOULD; use both validators in
+ cache-conditional requests. This allows both HTTP/1.0 and
+ HTTP/1.1 caches to respond appropriately.</t>
</list>
</t>
<t>
- <iref item="validator"/>
- <x:dfn>validator</x:dfn>
- <list>
- <t>
- A protocol element (e.g., an entity tag or a Last-Modified time)
- that is used to find out whether a cache entry is an equivalent
- copy of an entity.
- </t>
- </list>
+ An HTTP/1.1 origin server, upon receiving a conditional request that
+ includes both a Last-Modified date (e.g., in an If-Modified-Since or
+ If-Unmodified-Since header field) and one or more entity tags (e.g.,
+ in an If-Match, If-None-Match, or If-Range header field) as cache
+ validators, &MUST-NOT; return a response status of 304 (Not Modified)
+ unless doing so is consistent with all of the conditional header
+ fields in the request.
</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>
-<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"/>).
-</t>
-</section>
-</section>
-
-<section title="Notational Conventions and Generic Grammar">
-
-<section title="Augmented BNF">
-<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:
-</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>
-</t>
-<t>
- "literal"
- <list>
- <t>
- Quotation marks surround literal text. Unless stated otherwise,
- the text is case-insensitive.
- </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>
- </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>
-</t>
-<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>
- </list>
-</t>
-<t>
- [rule]
- <list>
- <t>
- Square brackets enclose optional elements; "[foo bar]" is
- equivalent to "*1(foo bar)".
- </t>
- </list>
-</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>
-</t>
-<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>
-</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>
-</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>
-</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"/>.
-</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.
-</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.
-</t>
-<t>
- Hexadecimal numeric characters are used in several protocol elements.
-</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.
-</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.
-</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>
-<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.
-</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.
-</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>
-</t>
-</section>
-
-<section title="Uniform Resource Identifiers" anchor="uri">
-<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"/>).
-</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>
-</t>
-</section>
-
-<section title="http URL" anchor="http.url">
-<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.
-</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.
-</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>
-</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.
-</t>
-<t>
- For example, the following three URIs are equivalent:
-</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="Full Date" anchor="full.date">
-<t>
- HTTP applications have historically allowed three different formats
- for the representation of date/time stamps:
-</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.
+ An HTTP/1.1 caching proxy, upon receiving a conditional request that
+ includes both a Last-Modified date and one or more entity tags as
+ cache validators, &MUST-NOT; return a locally cached response to the
+ client unless that cached response is consistent with all of the
+ conditional header fields in the request.
+ <list><t>
+ <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1
+ servers and clients should transmit as much non-redundant
+ information as is available in their responses and requests.
+ HTTP/1.1 systems receiving this information will make the most
+ conservative assumptions about the validators they receive.
+ </t><t>
+ HTTP/1.0 clients and caches will ignore entity tags. Generally,
+ last-modified values received or used by these systems will
+ support transparent and efficient caching, and so HTTP/1.1 origin
+ servers should provide Last-Modified values. In those rare cases
+ where the use of a Last-Modified value as a validator by an
+ HTTP/1.0 system could result in a serious problem, then HTTP/1.1
+ origin servers should not provide one.
+ </t></list>
</t>
</section>
-<section title="Delta Seconds">
+<section title="Header Field Definitions">
<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.
+ This section defines the syntax and semantics of all standard
+ HTTP/1.1 header fields. For entity-header fields, both sender and
+ recipient refer to either the client or the server, depending on who
+ sends and who receives the entity.
</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:
-</t>
+<section title="ETag" anchor="header.etag">
+ <iref primary="true" item="ETag header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="ETag" x:for-anchor=""/>
<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"/>.
+ The ETag response-header field provides the current value of the
+ entity tag for the requested variant. The headers used with entity
+ tags are described in sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag
+ &MAY; be used for comparison with other entities from the same resource
+ (see <xref target="weak.and.strong.validators"/>).
</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>
- charset = token
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/>
+ ETag = "ETag" ":" entity-tag
</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.
-</t>
-<t>
- Implementors should be aware of IETF character set requirements <xref target="RFC2279"/>
- <xref target="RFC2277"/>.
-</t>
-
-<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>
-<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"/>.
-</t>
-</section>
-</section>
-
-<section title="Content Codings" anchor="content.codings">
-<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.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>
- content-coding = token
+<figure><preamble>
+ Examples:
+</preamble>
+<artwork type="example">
+ ETag: "xyzzy"
+ ETag: W/"xyzzy"
+ ETag: ""
</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.
-</t>
-<t>
- The Internet Assigned Numbers Authority (IANA) acts as a registry for
- content-coding value tokens. Initially, the registry contains the
- following tokens:
-</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>
-</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>
-</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>
-</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>
-<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>
-<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>
+<section title="If-Match" anchor="header.if-match">
+ <iref primary="true" item="If-Match header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="If-Match" x:for-anchor=""/>
<t>
- Parameters are in the form of attribute/value pairs.
+ The If-Match request-header field is used with a method to make it
+ conditional. A client that has one or more entities previously
+ obtained from the resource can verify that one of those entities is
+ current by including a list of their associated entity tags in the
+ If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The
+ purpose of this feature is to allow efficient updates of cached
+ information with a minimum amount of transaction overhead. It is also
+ used, on updating requests, to prevent inadvertent modification of
+ the wrong version of a resource. As a special case, the value "*"
+ matches any current entity of the resource.
</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="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/>
+ If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
</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"/>).
+ If any of the entity tags match the entity tag of the entity that
+ would have been returned in the response to a similar GET request
+ (without the If-Match header) on that resource, or if "*" is given
+ and any current entity exists for that resource, then the server &MAY;
+ perform the requested method as if the If-Match header field did not
+ exist.
</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.
+ A server &MUST; use the strong comparison function (see <xref target="weak.and.strong.validators"/>)
+ to compare the entity tags in If-Match.
</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>
-<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.
-</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"/>).
-</t>
-<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>
-</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.
-</t>
-<t>
- An example process for decoding a Chunked-Body is presented in
- <xref target="introduction.of.transfer-encoding"/>.
-</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.
-</t>
-</section>
-</section>
-
-<section title="Media Types" anchor="media.types">
-<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.
-</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"/>).
-</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:
-</t>
-<figure><artwork type="example">
- User-Agent: CERN-LineMode/2.15 libwww/2.17b3
- Server: Apache/0.8.4
-</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).
-</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") ] )
-</artwork></figure>
-<t>
- "Quality values" is a misnomer, since these values merely represent
- relative degradation in desired quality.
-</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.
-</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:
-</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:
-</t>
-<figure><artwork type="example">
- en, en-US, en-cockney, i-cherokee, x-pig-latin
-</artwork></figure>
-<t>
- where any two-letter primary-tag is an ISO-639 language abbreviation
- and any two-letter initial subtag is an ISO-3166 country code. (The
- last three tags above are not registered tags; all but the last are
- examples of tags which could be registered in future.)
-</t>
-</section>
-
-<section title="Entity Tags" anchor="entity.tags">
-<t>
- Entity tags are used for comparing two or more entities from the same
- requested resource. HTTP/1.1 uses entity tags in the ETag (<xref target="header.etag"/>),
- If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and
- If-Range (<xref target="header.if-range"/>) header fields. The definition of how they
- are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An
- entity tag consists of an opaque quoted string, possibly prefixed by
- a weakness indicator.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-tag"/><iref primary="true" item="Grammar" subitem="weak"/><iref primary="true" item="Grammar" subitem="opaque-tag"/>
- entity-tag = [ weak ] opaque-tag
- weak = "W/"
- opaque-tag = quoted-string
-</artwork></figure>
-<t>
- A "strong entity tag" &MAY; be shared by two entities of a resource
- only if they are equivalent by octet equality.
-</t>
-<t>
- A "weak entity tag," indicated by the "W/" prefix, &MAY; be shared by
- two entities of a resource only if the entities are equivalent and
- could be substituted for each other with no significant change in
- semantics. A weak entity tag can only be used for weak comparison.
-</t>
-<t>
- An entity tag &MUST; be unique across all versions of all entities
- associated with a particular resource. A given entity tag value &MAY;
- be used for entities obtained by requests on different URIs. The use
- of the same entity tag value in conjunction with entities obtained by
- requests on different URIs does not imply the equivalence of those
- entities.
-</t>
-</section>
-
-<section title="Range Units" anchor="range.units">
-<t>
- HTTP/1.1 allows a client to request that only part (a range of) the
- response entity be included within the response. HTTP/1.1 uses range
- units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>)
- header fields. An entity can be broken down into subranges according
- to various structural units.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="range-unit"/><iref primary="true" item="Grammar" subitem="bytes-unit"/><iref primary="true" item="Grammar" subitem="other-range-unit"/>
- range-unit = bytes-unit | other-range-unit
- bytes-unit = "bytes"
- other-range-unit = token
-</artwork></figure>
-<t>
- The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
- implementations &MAY; ignore ranges specified using other units.
-</t>
-<t>
- HTTP/1.1 has been designed to allow implementations of applications
- that do not depend on knowledge of ranges.
-</t>
-</section>
-</section>
-
-
-
-
-<section title="HTTP Message" anchor="httpmessage">
-
-<section title="Message Types">
-<t>
- HTTP messages consist of requests from client to server and responses
- from server to client.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
- HTTP-message = Request | Response ; HTTP/1.1 messages
-</artwork></figure>
-<t>
- Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
- message format of RFC 822 <xref target="RFC822"/> for transferring entities (the payload
- of the message). Both types of message consist of a start-line, zero
- or more header fields (also known as "headers"), an empty line (i.e.,
- a line with nothing preceding the CRLF) indicating the end of the
- header fields, and possibly a message-body.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="generic-message"/><iref primary="true" item="Grammar" subitem="start-line"/>
- generic-message = start-line
- *(message-header CRLF)
- CRLF
- [ message-body ]
- start-line = Request-Line | Status-Line
-</artwork></figure>
-<t>
- In the interest of robustness, servers &SHOULD; ignore any empty
- line(s) received where a Request-Line is expected. In other words, if
- the server is reading the protocol stream at the beginning of a
- message and receives a CRLF first, it should ignore the CRLF.
-</t>
-<t>
- Certain buggy HTTP/1.0 client implementations generate extra CRLF's
- after a POST request. To restate what is explicitly forbidden by the
- BNF, an HTTP/1.1 client &MUST-NOT; preface or follow a request with an
- extra CRLF.
-</t>
-</section>
-
-<section title="Message Headers" anchor="message.headers">
-<t>
- HTTP header fields, which include general-header (<xref target="general.header.fields"/>),
- request-header (<xref target="request.header.fields"/>), response-header (<xref target="response.header.fields"/>), and
- entity-header (<xref target="entity.header.fields"/>) fields, follow the same generic format as
- that given in <xref target="RFC822" x:fmt="sec" x:sec="3.1"/> of RFC 822 <xref target="RFC822"/>. Each header field consists
- of a name followed by a colon (":") and the field value. Field names
[... 9840 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org