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/11/13 04:52:29 UTC
svn commit: r594419 [8/16] - /labs/webarch/trunk/http/draft-fielding-http/00/
Added: labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p2-semantics-00.xml
URL: http://svn.apache.org/viewvc/labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p2-semantics-00.xml?rev=594419&view=auto
==============================================================================
--- labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p2-semantics-00.xml (added)
+++ labs/webarch/trunk/http/draft-fielding-http/00/draft-fielding-http-p2-semantics-00.xml Mon Nov 12 19:52:28 2007
@@ -0,0 +1,2324 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE rfc [
+ <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
+ <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
+ <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
+ <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
+ <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
+ <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
+ <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
+ <!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 payload "[Part 3]">
+ <!ENTITY conditional "[Part 4]">
+ <!ENTITY range "[Part 5]">
+ <!ENTITY caching "[Part 6]">
+ <!ENTITY auth "[Part 7]">
+ <!ENTITY content-negotiation "[Part 3]">
+ <!ENTITY diff2045entity "[Part 3]">
+ <!ENTITY uri "[Part 1]">
+ <!ENTITY http-url "[Part 1]">
+ <!ENTITY http-version "[Part 1]">
+ <!ENTITY use100 "[Part 1]">
+ <!ENTITY qvalue "[Part 3]">
+ <!ENTITY header-accept "[Part 3]">
+ <!ENTITY header-accept-charset "[Part 3]">
+ <!ENTITY header-accept-encoding "[Part 3]">
+ <!ENTITY header-accept-language "[Part 3]">
+ <!ENTITY header-accept-ranges "[Part 3]">
+ <!ENTITY header-age "[Part 6]">
+ <!ENTITY header-authorization "[Part 7]">
+ <!ENTITY header-cache-control "[Part 6]">
+ <!ENTITY header-content-location "[Part 3]">
+ <!ENTITY header-content-range "[Part 5]">
+ <!ENTITY header-etag "[Part 4]">
+ <!ENTITY header-expires "[Part 6]">
+ <!ENTITY header-host "[Part 1]">
+ <!ENTITY header-if-match "[Part 4]">
+ <!ENTITY header-if-modified-since "[Part 4]">
+ <!ENTITY header-if-none-match "[Part 4]">
+ <!ENTITY header-if-range "[Part 5]">
+ <!ENTITY header-if-unmodified-since "[Part 4]">
+ <!ENTITY header-pragma "[Part 6]">
+ <!ENTITY header-proxy-authenticate "[Part 7]">
+ <!ENTITY header-proxy-authorization "[Part 7]">
+ <!ENTITY header-range "[Part 5]">
+ <!ENTITY header-upgrade "[Part 1]">
+ <!ENTITY header-te "[Part 1]">
+ <!ENTITY header-vary "[Part 6]">
+ <!ENTITY header-via "[Part 1]">
+ <!ENTITY header-warning "[Part 6]">
+ <!ENTITY header-www-authenticate "[Part 7]">
+ <!ENTITY message-body "[Part 1]">
+]>
+<?rfc toc="yes" ?>
+<?rfc symrefs="yes" ?>
+<?rfc sortrefs="yes" ?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no" ?>
+<?rfc linkmailto="no" ?>
+<?rfc editing="no" ?>
+<?rfc-ext allow-markup-in-artwork="yes" ?>
+<?rfc-ext include-references-in-index="yes" ?>
+<rfc obsoletes="2068, 2616, 2617" category="std"
+ ipr="full3978" docName="draft-fielding-http-p2-semantics-00"
+ xmlns:x='http://purl.org/net/xml2rfc/ext' xmlns:ed="http://greenbytes.de/2002/rfcedit">
+<front>
+
+ <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>
+
+ <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
+ <organization abbrev="Day Software">Day Software</organization>
+ <address>
+ <postal>
+ <street>23 Corporate Plaza DR, Suite 280</street>
+ <city>Newport Beach</city>
+ <region>CA</region>
+ <code>92660</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1-949-706-5300</phone>
+ <facsimile>+1-949-706-5305</facsimile>
+ <email>fielding@gbiv.com</email>
+ <uri>http://roy.gbiv.com/</uri>
+ </address>
+ </author>
+
+ <author initials="J." surname="Gettys" fullname="James Gettys">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Cambridge Research Laboratory</street>
+ <street>One Cambridge Center</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02138</code>
+ <country>USA</country>
+ </postal>
+ <email>Jim.Gettys@hp.com</email>
+ </address>
+ </author>
+
+ <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="HP">Hewlett-Packard Company</organization>
+ <address>
+ <postal>
+ <street>HP Labs, Large Scale Systems Group</street>
+ <street>1501 Page Mill Road, MS 1177</street>
+ <city>Palo Alto</city>
+ <region>CA</region>
+ <code>94304</code>
+ <country>USA</country>
+ </postal>
+ <email>JeffMogul@acm.org</email>
+ </address>
+ </author>
+
+ <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ <country>USA</country>
+ </postal>
+ <email>henrikn@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization abbrev="Adobe Systems">Adobe Systems, Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city>
+ <region>CA</region>
+ <code>95110</code>
+ <country>USA</country>
+ </postal>
+ <email>LMM@acm.org</email>
+ <uri>http://larry.masinter.net/</uri>
+ </address>
+ </author>
+
+ <author initials="P." surname="Leach" fullname="Paul J. Leach">
+ <organization abbrev="Microsoft">Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city>
+ <region>WA</region>
+ <code>98052</code>
+ </postal>
+ <email>paulle@microsoft.com</email>
+ </address>
+ </author>
+
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city>
+ <region>MA</region>
+ <code>02139</code>
+ <country>USA</country>
+ </postal>
+ <facsimile>+1 (617) 258 8682</facsimile>
+ <email>timbl@w3.org</email>
+ </address>
+ </author>
+
+ <date month="November" year="2007"/>
+
+<abstract>
+<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. This document is Part 2 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 2 defines the semantics of HTTP messages
+ as expressed by request methods, request-header fields, response status codes,
+ and response-header fields.
+</t>
+</abstract>
+</front>
+<middle>
+<section title="Introduction" anchor="introduction">
+<t>
+ This document will define aspects of HTTP related to request and response
+ semantics. Right now it only includes the extracted relevant sections of
+ RFC 2616 with only minor edits.
+</t>
+<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 &diff2045entity;.
+</t>
+</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="Method" anchor="method">
+<t>
+ The Method token indicates the method to be performed on the
+ resource identified by the Request-URI. The method is case-sensitive.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
+ Method = "OPTIONS" ; <xref target="OPTIONS"/>
+ | "GET" ; <xref target="GET"/>
+ | "HEAD" ; <xref target="HEAD"/>
+ | "POST" ; <xref target="POST"/>
+ | "PUT" ; <xref target="PUT"/>
+ | "DELETE" ; <xref target="DELETE"/>
+ | "TRACE" ; <xref target="TRACE"/>
+ | "CONNECT" ; <xref target="CONNECT"/>
+ | extension-method
+ extension-method = token
+</artwork></figure>
+<t>
+ The list of methods allowed by a resource can be specified in an
+ Allow header field (<xref target="header.allow"/>). The return code of the response
+ always notifies the client whether a method is currently allowed on a
+ resource, since the set of allowed methods can change dynamically. An
+ origin server &SHOULD; return the status code 405 (Method Not Allowed)
+ if the method is known by the origin server but not allowed for the
+ requested resource, and 501 (Not Implemented) if the method is
+ unrecognized or not implemented by the origin server. The methods GET
+ and HEAD &MUST; be supported by all general-purpose servers. All other
+ methods are &OPTIONAL;; however, if the above methods are implemented,
+ they &MUST; be implemented with the same semantics as those specified
+ in <xref target="method.definitions"/>.
+</t>
+</section>
+
+<section title="Request Header Fields" anchor="request.header.fields">
+<t>
+ The request-header fields allow the client to pass additional
+ information about the request, and about the client itself, to the
+ server. These fields act as request modifiers, with semantics
+ equivalent to the parameters on a programming language method
+ invocation.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-header"/>
+ request-header = Accept ; &header-accept;
+ | Accept-Charset ; &header-accept-charset;
+ | Accept-Encoding ; &header-accept-encoding;
+ | Accept-Language ; &header-accept-language;
+ | Authorization ; &header-authorization;
+ | Expect ; <xref target="header.expect"/>
+ | From ; <xref target="header.from"/>
+ | Host ; &header-host;
+ | If-Match ; &header-if-match;
+ | If-Modified-Since ; &header-if-modified-since;
+ | If-None-Match ; &header-if-none-match;
+ | If-Range ; &header-if-range;
+ | If-Unmodified-Since ; &header-if-unmodified-since;
+ | Max-Forwards ; <xref target="header.max-forwards"/>
+ | Proxy-Authorization ; &header-proxy-authorization;
+ | Range ; &header-range;
+ | Referer ; <xref target="header.referer"/>
+ | TE ; &header-te;
+ | User-Agent ; <xref target="header.user-agent"/>
+</artwork></figure>
+<t>
+ Request-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields &MAY; be given the semantics of request-header
+ fields if all parties in the communication recognize them to
+ be request-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+</t>
+</section>
+
+<section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase">
+<t>
+ The Status-Code element is a 3-digit integer result code of the
+ attempt to understand and satisfy the request. These codes are fully
+ defined in <xref target="status.codes"/>. The Reason-Phrase is intended to give a short
+ textual description of the Status-Code. The Status-Code is intended
+ for use by automata and the Reason-Phrase is intended for the human
+ user. The client is not required to examine or display the Reason-Phrase.
+</t>
+<t>
+ The individual values of the numeric status codes defined for
+ HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+ presented below. The reason phrases listed here are only
+ recommendations -- they &MAY; be replaced by local equivalents without
+ affecting the protocol.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/>
+ Status-Code =
+ "100" ; <xref target="status.100"/>: Continue
+ | "101" ; <xref target="status.101"/>: Switching Protocols
+ | "200" ; <xref target="status.200"/>: OK
+ | "201" ; <xref target="status.201"/>: Created
+ | "202" ; <xref target="status.202"/>: Accepted
+ | "203" ; <xref target="status.203"/>: Non-Authoritative Information
+ | "204" ; <xref target="status.204"/>: No Content
+ | "205" ; <xref target="status.205"/>: Reset Content
+ | "206" ; <xref target="status.206"/>: Partial Content
+ | "300" ; <xref target="status.300"/>: Multiple Choices
+ | "301" ; <xref target="status.301"/>: Moved Permanently
+ | "302" ; <xref target="status.302"/>: Found
+ | "303" ; <xref target="status.303"/>: See Other
+ | "304" ; <xref target="status.304"/>: Not Modified
+ | "305" ; <xref target="status.305"/>: Use Proxy
+ | "307" ; <xref target="status.307"/>: Temporary Redirect
+ | "400" ; <xref target="status.400"/>: Bad Request
+ | "401" ; <xref target="status.401"/>: Unauthorized
+ | "402" ; <xref target="status.402"/>: Payment Required
+ | "403" ; <xref target="status.403"/>: Forbidden
+ | "404" ; <xref target="status.404"/>: Not Found
+ | "405" ; <xref target="status.405"/>: Method Not Allowed
+ | "406" ; <xref target="status.406"/>: Not Acceptable
+ | "407" ; <xref target="status.407"/>: Proxy Authentication Required
+ | "408" ; <xref target="status.408"/>: Request Time-out
+ | "409" ; <xref target="status.409"/>: Conflict
+ | "410" ; <xref target="status.410"/>: Gone
+ | "411" ; <xref target="status.411"/>: Length Required
+ | "412" ; <xref target="status.412"/>: Precondition Failed
+ | "413" ; <xref target="status.413"/>: Request Entity Too Large
+ | "414" ; <xref target="status.414"/>: Request-URI Too Large
+ | "415" ; <xref target="status.415"/>: Unsupported Media Type
+ | "416" ; <xref target="status.416"/>: Requested range not satisfiable
+ | "417" ; <xref target="status.417"/>: Expectation Failed
+ | "500" ; <xref target="status.500"/>: Internal Server Error
+ | "501" ; <xref target="status.501"/>: Not Implemented
+ | "502" ; <xref target="status.502"/>: Bad Gateway
+ | "503" ; <xref target="status.503"/>: Service Unavailable
+ | "504" ; <xref target="status.504"/>: Gateway Time-out
+ | "505" ; <xref target="status.505"/>: HTTP Version not supported
+ | extension-code
+
+ extension-code = 3DIGIT
+ Reason-Phrase = *<TEXT, excluding CR, LF>
+</artwork></figure>
+<t>
+ HTTP status codes are extensible. HTTP applications are not required
+ to understand the meaning of all registered status codes, though such
+ understanding is obviously desirable. However, applications &MUST;
+ understand the class of any status code, as indicated by the first
+ digit, and treat any unrecognized response as being equivalent to the
+ x00 status code of that class, with the exception that an
+ unrecognized response &MUST-NOT; be cached. For example, if an
+ unrecognized status code of 431 is received by the client, it can
+ safely assume that there was something wrong with its request and
+ treat the response as if it had received a 400 status code. In such
+ cases, user agents &SHOULD; present to the user the entity returned
+ with the response, since that entity is likely to include human-readable
+ information which will explain the unusual status.
+</t>
+</section>
+
+<section title="Response Header Fields" anchor="response.header.fields">
+<t>
+ The response-header fields allow the server to pass additional
+ information about the response which cannot be placed in the Status-Line.
+ These header fields give information about the server and about
+ further access to the resource identified by the Request-URI.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/>
+ response-header = Accept-Ranges ; &header-accept-ranges;
+ | Age ; &header-age;
+ | ETag ; &header-etag;
+ | Location ; <xref target="header.location"/>
+ | Proxy-Authenticate ; &header-proxy-authenticate;
+ | Retry-After ; <xref target="header.retry-after"/>
+ | Server ; <xref target="header.server"/>
+ | Vary ; &header-vary;
+ | WWW-Authenticate ; &header-www-authenticate;
+</artwork></figure>
+<t>
+ Response-header field names can be extended reliably only in
+ combination with a change in the protocol version. However, new or
+ experimental header fields &MAY; be given the semantics of response-header
+ fields if all parties in the communication recognize them to
+ be response-header fields. Unrecognized header fields are treated as
+ entity-header fields.
+</t>
+</section>
+
+<section title="Entity" anchor="entity">
+<t>
+ Request and Response messages &MAY; transfer an entity if not otherwise
+ restricted by the request method or response status code. An entity
+ consists of entity-header fields and an entity-body, although some
+ responses will only include the entity-headers. HTTP entity-body and
+ entity-header fields are defined in &payload;.
+</t>
+<t>
+ An entity-body is only present in a message when a message-body is
+ present, as described in &message-body;. The entity-body is obtained
+ from the message-body by decoding any Transfer-Encoding that might
+ have been applied to ensure safe and proper transfer of the message.
+</t>
+</section>
+
+
+<section title="Method Definitions" anchor="method.definitions">
+<t>
+ The set of common methods for HTTP/1.1 is defined below. Although
+ this set can be expanded, additional methods cannot be assumed to
+ share the same semantics for separately extended clients and servers.
+
+ The Host request-header field (&header-host;) &MUST; accompany all
+ HTTP/1.1 requests.
+</t>
+
+<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
+
+<section title="Safe Methods" anchor="safe.methods">
+<t>
+ Implementors should be aware that the software represents the user in
+ their interactions over the Internet, and should be careful to allow
+ the user to be aware of any actions they might take which may have an
+ unexpected significance to themselves or others.
+</t>
+<t>
+ In particular, the convention has been established that the GET and
+ HEAD methods &SHOULD-NOT; have the significance of taking an action
+ other than retrieval. These methods ought to be considered "safe".
+ This allows user agents to represent other methods, such as POST, PUT
+ and DELETE, in a special way, so that the user is made aware of the
+ fact that a possibly unsafe action is being requested.
+</t>
+<t>
+ Naturally, it is not possible to ensure that the server does not
+ generate side-effects as a result of performing a GET request; in
+ fact, some dynamic resources consider that a feature. The important
+ distinction here is that the user did not request the side-effects,
+ so therefore cannot be held accountable for them.
+</t>
+</section>
+
+<section title="Idempotent Methods" anchor="idempotent.methods">
+<t>
+ Methods can also have the property of "idempotence" in that (aside
+ from error or expiration issues) the side-effects of N > 0 identical
+ requests is the same as for a single request. The methods GET, HEAD,
+ PUT and DELETE share this property. Also, the methods OPTIONS and
+ TRACE &SHOULD-NOT; have side effects, and so are inherently idempotent.
+</t>
+<t>
+ However, it is possible that a sequence of several requests is non-idempotent,
+ even if all of the methods executed in that sequence are
+ idempotent. (A sequence is idempotent if a single execution of the
+ entire sequence always yields a result that is not changed by a
+ reexecution of all, or part, of that sequence.) For example, a
+ sequence is non-idempotent if its result depends on a value that is
+ later modified in the same sequence.
+</t>
+<t>
+ A sequence that never has side effects is idempotent, by definition
+ (provided that no concurrent operations are being executed on the
+ same set of resources).
+</t>
+</section>
+</section>
+
+<section title="OPTIONS" anchor="OPTIONS">
+ <iref primary="true" item="OPTIONS method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>
+<t>
+ The OPTIONS method represents a request for information about the
+ communication options available on the request/response chain
+ identified by the Request-URI. This method allows the client to
+ determine the options and/or requirements associated with a resource,
+ or the capabilities of a server, without implying a resource action
+ or initiating a resource retrieval.
+</t>
+<t>
+ Responses to this method are not cacheable.
+</t>
+<t>
+ If the OPTIONS request includes an entity-body (as indicated by the
+ presence of Content-Length or Transfer-Encoding), then the media type
+ &MUST; be indicated by a Content-Type field. Although this
+ specification does not define any use for such a body, future
+ extensions to HTTP might use the OPTIONS body to make more detailed
+ queries on the server. A server that does not support such an
+ extension &MAY; discard the request body.
+</t>
+<t>
+ If the Request-URI is an asterisk ("*"), the OPTIONS request is
+ intended to apply to the server in general rather than to a specific
+ resource. Since a server's communication options typically depend on
+ the resource, the "*" request is only useful as a "ping" or "no-op"
+ type of method; it does nothing beyond allowing the client to test
+ the capabilities of the server. For example, this can be used to test
+ a proxy for HTTP/1.1 compliance (or lack thereof).
+</t>
+<t>
+ If the Request-URI is not an asterisk, the OPTIONS request applies
+ only to the options that are available when communicating with that
+ resource.
+</t>
+<t>
+ A 200 response &SHOULD; include any header fields that indicate
+ optional features implemented by the server and applicable to that
+ resource (e.g., Allow), possibly including extensions not defined by
+ this specification. The response body, if any, &SHOULD; also include
+ information about the communication options. The format for such a
+ body is not defined by this specification, but might be defined by
+ future extensions to HTTP. Content negotiation &MAY; be used to select
+ the appropriate response format. If no response body is included, the
+ response &MUST; include a Content-Length field with a field-value of
+ "0".
+</t>
+<t>
+ The Max-Forwards request-header field &MAY; be used to target a
+ specific proxy in the request chain. When a proxy receives an OPTIONS
+ request on an absoluteURI for which request forwarding is permitted,
+ the proxy &MUST; check for a Max-Forwards field. If the Max-Forwards
+ field-value is zero ("0"), the proxy &MUST-NOT; forward the message;
+ instead, the proxy &SHOULD; respond with its own communication options.
+ If the Max-Forwards field-value is an integer greater than zero, the
+ proxy &MUST; decrement the field-value when it forwards the request. If
+ no Max-Forwards field is present in the request, then the forwarded
+ request &MUST-NOT; include a Max-Forwards field.
+</t>
+</section>
+
+<section title="GET" anchor="GET">
+ <iref primary="true" item="GET method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>
+<t>
+ The GET method means retrieve whatever information (in the form of an
+ entity) is identified by the Request-URI. If the Request-URI refers
+ to a data-producing process, it is the produced data which shall be
+ returned as the entity in the response and not the source text of the
+ process, unless that text happens to be the output of the process.
+</t>
+<t>
+ The semantics of the GET method change to a "conditional GET" if the
+ request message includes an If-Modified-Since, If-Unmodified-Since,
+ If-Match, If-None-Match, or If-Range header field. A conditional GET
+ method requests that the entity be transferred only under the
+ circumstances described by the conditional header field(s). The
+ conditional GET method is intended to reduce unnecessary network
+ usage by allowing cached entities to be refreshed without requiring
+ multiple requests or transferring data already held by the client.
+</t>
+<t>
+ The semantics of the GET method change to a "partial GET" if the
+ request message includes a Range header field. A partial GET requests
+ that only part of the entity be transferred, as described in &header-range;.
+ The partial GET method is intended to reduce unnecessary
+ network usage by allowing partially-retrieved entities to be
+ completed without transferring data already held by the client.
+</t>
+<t>
+ The response to a GET request is cacheable if and only if it meets
+ the requirements for HTTP caching described in &caching;.
+</t>
+<t>
+ See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
+</t>
+</section>
+
+<section title="HEAD" anchor="HEAD">
+ <iref primary="true" item="HEAD method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>
+<t>
+ The HEAD method is identical to GET except that the server &MUST-NOT;
+ return a message-body in the response. The metainformation contained
+ in the HTTP headers in response to a HEAD request &SHOULD; be identical
+ to the information sent in response to a GET request. This method can
+ be used for obtaining metainformation about the entity implied by the
+ request without transferring the entity-body itself. This method is
+ often used for testing hypertext links for validity, accessibility,
+ and recent modification.
+</t>
+<t>
+ The response to a HEAD request &MAY; be cacheable in the sense that the
+ information contained in the response &MAY; be used to update a
+ previously cached entity from that resource. If the new field values
+ indicate that the cached entity differs from the current entity (as
+ would be indicated by a change in Content-Length, Content-MD5, ETag
+ or Last-Modified), then the cache &MUST; treat the cache entry as
+ stale.
+</t>
+</section>
+
+<section title="POST" anchor="POST">
+ <iref primary="true" item="POST method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>
+<t>
+ The POST method is used to request that the origin server accept the
+ entity enclosed in the request as data to be processed by the resource
+ identified by the Request-URI in the Request-Line. POST is designed
+ to allow a uniform method to cover the following functions:
+ <list style="symbols">
+ <t>
+ Annotation of existing resources;
+ </t>
+ <t>
+ Posting a message to a bulletin board, newsgroup, mailing list,
+ or similar group of articles;
+ </t>
+ <t>
+ Providing a block of data, such as the result of submitting a
+ form, to a data-handling process;
+ </t>
+ <t>
+ Extending a database through an append operation.
+ </t>
+ </list>
+</t>
+<t>
+ The actual function performed by the POST method is determined by the
+ server and is usually dependent on the Request-URI.
+</t>
+<t>
+ The action performed by the POST method might not result in a
+ resource that can be identified by a URI. In this case, either 200
+ (OK) or 204 (No Content) is the appropriate response status,
+ depending on whether or not the response includes an entity that
+ describes the result.
+</t>
+<t>
+ If a resource has been created on the origin server, the response
+ &SHOULD; be 201 (Created) and contain an entity which describes the
+ status of the request and refers to the new resource, and a Location
+ header (see <xref target="header.location"/>).
+</t>
+<t>
+ Responses to this method are not cacheable, unless the response
+ includes appropriate Cache-Control or Expires header fields. However,
+ the 303 (See Other) response can be used to direct the user agent to
+ retrieve a cacheable resource.
+</t>
+<t>
+ POST requests &MUST; obey the message transmission requirements set out
+ in [message.transmission.requirements].
+</t>
+<t>
+ See <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
+</t>
+</section>
+
+<section title="PUT" anchor="PUT">
+ <iref primary="true" item="PUT method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>
+<t>
+ The PUT method requests that the enclosed entity be stored under the
+ supplied Request-URI. If the Request-URI refers to an already
+ existing resource, the enclosed entity &SHOULD; be considered as a
+ modified version of the one residing on the origin server. If the
+ Request-URI does not point to an existing resource, and that URI is
+ capable of being defined as a new resource by the requesting user
+ agent, the origin server can create the resource with that URI. If a
+ new resource is created, the origin server &MUST; inform the user agent
+ via the 201 (Created) response. If an existing resource is modified,
+ either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent
+ to indicate successful completion of the request. If the resource
+ could not be created or modified with the Request-URI, an appropriate
+ error response &SHOULD; be given that reflects the nature of the
+ problem. The recipient of the entity &MUST-NOT; ignore any Content-*
+ (e.g. Content-Range) headers that it does not understand or implement
+ and &MUST; return a 501 (Not Implemented) response in such cases.
+</t>
+<t>
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries &SHOULD; be
+ treated as stale. Responses to this method are not cacheable.
+</t>
+<t>
+ The fundamental difference between the POST and PUT requests is
+ reflected in the different meaning of the Request-URI. The URI in a
+ POST request identifies the resource that will handle the enclosed
+ entity. That resource might be a data-accepting process, a gateway to
+ some other protocol, or a separate entity that accepts annotations.
+ In contrast, the URI in a PUT request identifies the entity enclosed
+ with the request -- the user agent knows what URI is intended and the
+ server &MUST-NOT; attempt to apply the request to some other resource.
+ If the server desires that the request be applied to a different URI,
+ it &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;
+ then make its own decision regarding whether or not to redirect the
+ request.
+</t>
+<t>
+ A single resource &MAY; be identified by many different URIs. For
+ example, an article might have a URI for identifying "the current
+ version" which is separate from the URI identifying each particular
+ version. In this case, a PUT request on a general URI might result in
+ several other URIs being defined by the origin server.
+</t>
+<t>
+ HTTP/1.1 does not define how a PUT method affects the state of an
+ origin server.
+</t>
+<t>
+ PUT requests &MUST; obey the message transmission requirements set out
+ in [message.transmission.requirements].
+</t>
+<t>
+ Unless otherwise specified for a particular entity-header, the
+ entity-headers in the PUT request &SHOULD; be applied to the resource
+ created or modified by the PUT.
+</t>
+</section>
+
+<section title="DELETE" anchor="DELETE">
+ <iref primary="true" item="DELETE method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>
+<t>
+ The DELETE method requests that the origin server delete the resource
+ identified by the Request-URI. This method &MAY; be overridden by human
+ intervention (or other means) on the origin server. The client cannot
+ be guaranteed that the operation has been carried out, even if the
+ status code returned from the origin server indicates that the action
+ has been completed successfully. However, the server &SHOULD-NOT;
+ indicate success unless, at the time the response is given, it
+ intends to delete the resource or move it to an inaccessible
+ location.
+</t>
+<t>
+ A successful response &SHOULD; be 200 (OK) if the response includes an
+ entity describing the status, 202 (Accepted) if the action has not
+ yet been enacted, or 204 (No Content) if the action has been enacted
+ but the response does not include an entity.
+</t>
+<t>
+ If the request passes through a cache and the Request-URI identifies
+ one or more currently cached entities, those entries &SHOULD; be
+ treated as stale. Responses to this method are not cacheable.
+</t>
+</section>
+
+<section title="TRACE" anchor="TRACE">
+ <iref primary="true" item="TRACE method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>
+<t>
+ The TRACE method is used to invoke a remote, application-layer loop-back
+ of the request message. The final recipient of the request
+ &SHOULD; reflect the message received back to the client as the
+ entity-body of a 200 (OK) response. The final recipient is either the
+ origin server or the first proxy or gateway to receive a Max-Forwards
+ value of zero (0) in the request (see <xref target="header.max-forwards"/>). A TRACE request
+ &MUST-NOT; include an entity.
+</t>
+<t>
+ TRACE allows the client to see what is being received at the other
+ end of the request chain and use that data for testing or diagnostic
+ information. The value of the Via header field (&header-via;) is of
+ particular interest, since it acts as a trace of the request chain.
+ Use of the Max-Forwards header field allows the client to limit the
+ length of the request chain, which is useful for testing a chain of
+ proxies forwarding messages in an infinite loop.
+</t>
+<t>
+ If the request is valid, the response &SHOULD; contain the entire
+ request message in the entity-body, with a Content-Type of
+ "message/http". Responses to this method &MUST-NOT; be cached.
+</t>
+</section>
+
+<section title="CONNECT" anchor="CONNECT">
+ <iref primary="true" item="CONNECT method" x:for-anchor=""/>
+ <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>
+<t>
+ This specification reserves the method name CONNECT for use with a
+ proxy that can dynamically switch to being a tunnel (e.g. SSL
+ tunneling <xref target="Luo1998"/>).
+</t>
+</section>
+</section>
+
+
+<section title="Status Code Definitions" anchor="status.codes">
+<t>
+ Each Status-Code is described below, including a description of which
+ method(s) it can follow and any metainformation required in the
+ response.
+</t>
+
+<section title="Informational 1xx" anchor="status.1xx">
+<t>
+ This class of status code indicates a provisional response,
+ consisting only of the Status-Line and optional headers, and is
+ terminated by an empty line. There are no required headers for this
+ class of status code. Since HTTP/1.0 did not define any 1xx status
+ codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client
+ except under experimental conditions.
+</t>
+<t>
+ A client &MUST; be prepared to accept one or more 1xx status responses
+ prior to a regular response, even if the client does not expect a 100
+ (Continue) status message. Unexpected 1xx status responses &MAY; be
+ ignored by a user agent.
+</t>
+<t>
+ Proxies &MUST; forward 1xx responses, unless the connection between the
+ proxy and its client has been closed, or unless the proxy itself
+ requested the generation of the 1xx response. (For example, if a
+ proxy adds a "Expect: 100-continue" field when it forwards a request,
+ then it need not forward the corresponding 100 (Continue)
+ response(s).)
+</t>
+
+<section title="100 Continue" anchor="status.100">
+ <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/>
+<t>
+ The client &SHOULD; continue with its request. This interim response is
+ used to inform the client that the initial part of the request has
+ been received and has not yet been rejected by the server. The client
+ &SHOULD; continue by sending the remainder of the request or, if the
+ request has already been completed, ignore this response. The server
+ &MUST; send a final response after the request has been completed. See
+ &use100; for detailed discussion of the use and handling of this
+ status code.
+</t>
+</section>
+
+<section title="101 Switching Protocols" anchor="status.101">
+ <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/>
+<t>
+ The server understands and is willing to comply with the client's
+ request, via the Upgrade message header field (&header-upgrade;), for a
+ change in the application protocol being used on this connection. The
+ server will switch protocols to those defined by the response's
+ Upgrade header field immediately after the empty line which
+ terminates the 101 response.
+</t>
+<t>
+ The protocol &SHOULD; be switched only when it is advantageous to do
+ so. For example, switching to a newer version of HTTP is advantageous
+ over older versions, and switching to a real-time, synchronous
+ protocol might be advantageous when delivering resources that use
+ such features.
+</t>
+</section>
+</section>
+
+<section title="Successful 2xx" anchor="status.2xx">
+<t>
+ This class of status code indicates that the client's request was
+ successfully received, understood, and accepted.
+</t>
+
+<section title="200 OK" anchor="status.200">
+ <iref primary="true" item="200 OK (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/>
+<t>
+ The request has succeeded. The information returned with the response
+ is dependent on the method used in the request, for example:
+ <list style="hanging">
+ <t hangText="GET">
+ an entity corresponding to the requested resource is sent in
+ the response;
+ </t>
+ <t hangText="HEAD">
+ the entity-header fields corresponding to the requested
+ resource are sent in the response without any message-body;
+ </t>
+ <t hangText="POST">
+ an entity describing or containing the result of the action;
+ </t>
+ <t hangText="TRACE">
+ an entity containing the request message as received by the
+ end server.
+ </t>
+ </list>
+</t>
+</section>
+
+<section title="201 Created" anchor="status.201">
+ <iref primary="true" item="201 Created (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/>
+<t>
+ The request has been fulfilled and resulted in a new resource being
+ created. The newly created resource can be referenced by the URI(s)
+ returned in the entity of the response, with the most specific URI
+ for the resource given by a Location header field. The response
+ &SHOULD; include an entity containing a list of resource
+ characteristics and location(s) from which the user or user agent can
+ choose the one most appropriate. The entity format is specified by
+ the media type given in the Content-Type header field. The origin
+ server &MUST; create the resource before returning the 201 status code.
+ If the action cannot be carried out immediately, the server &SHOULD;
+ respond with 202 (Accepted) response instead.
+</t>
+<t>
+ A 201 response &MAY; contain an ETag response header field indicating
+ the current value of the entity tag for the requested variant just
+ created, see &header-etag;.
+</t>
+</section>
+
+<section title="202 Accepted" anchor="status.202">
+ <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/>
+<t>
+ The request has been accepted for processing, but the processing has
+ not been completed. The request might or might not eventually be
+ acted upon, as it might be disallowed when processing actually takes
+ place. There is no facility for re-sending a status code from an
+ asynchronous operation such as this.
+</t>
+<t>
+ The 202 response is intentionally non-committal. Its purpose is to
+ allow a server to accept a request for some other process (perhaps a
+ batch-oriented process that is only run once per day) without
+ requiring that the user agent's connection to the server persist
+ until the process is completed. The entity returned with this
+ response &SHOULD; include an indication of the request's current status
+ and either a pointer to a status monitor or some estimate of when the
+ user can expect the request to be fulfilled.
+</t>
+</section>
+
+<section title="203 Non-Authoritative Information" anchor="status.203">
+ <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
+<t>
+ The returned metainformation in the entity-header is not the
+ definitive set as available from the origin server, but is gathered
+ from a local or a third-party copy. The set presented &MAY; be a subset
+ or superset of the original version. For example, including local
+ annotation information about the resource might result in a superset
+ of the metainformation known by the origin server. Use of this
+ response code is not required and is only appropriate when the
+ response would otherwise be 200 (OK).
+</t>
+</section>
+
+<section title="204 No Content" anchor="status.204">
+ <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/>
+<t>
+ The server has fulfilled the request but does not need to return an
+ entity-body, and might want to return updated metainformation. The
+ response &MAY; include new or updated metainformation in the form of
+ entity-headers, which if present &SHOULD; be associated with the
+ requested variant.
+</t>
+<t>
+ If the client is a user agent, it &SHOULD-NOT; change its document view
+ from that which caused the request to be sent. This response is
+ primarily intended to allow input for actions to take place without
+ causing a change to the user agent's active document view, although
+ any new or updated metainformation &SHOULD; be applied to the document
+ currently in the user agent's active view.
+</t>
+<t>
+ The 204 response &MUST-NOT; include a message-body, and thus is always
+ terminated by the first empty line after the header fields.
+</t>
+</section>
+
+<section title="205 Reset Content" anchor="status.205">
+ <iref primary="true" item="205 Reset Content (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="205 Reset Content" x:for-anchor=""/>
+<t>
+ The server has fulfilled the request and the user agent &SHOULD; reset
+ the document view which caused the request to be sent. This response
+ is primarily intended to allow input for actions to take place via
+ user input, followed by a clearing of the form in which the input is
+ given so that the user can easily initiate another input action. The
+ response &MUST-NOT; include an entity.
+</t>
+</section>
+
+<section title="206 Partial Content" anchor="status.206">
+ <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
+<t>
+ The server has fulfilled the partial GET request for the resource
+ and the enclosed entity is a partial representation as defined in ⦥.
+</t>
+</section>
+</section>
+
+<section title="Redirection 3xx" anchor="status.3xx">
+<t>
+ This class of status code indicates that further action needs to be
+ taken by the user agent in order to fulfill the request. The action
+ required &MAY; be carried out by the user agent without interaction
+ with the user if and only if the method used in the second request is
+ GET or HEAD. A client &SHOULD; detect infinite redirection loops, since
+ such loops generate network traffic for each redirection.
+ <list><t>
+ <x:h>Note:</x:h> previous versions of this specification recommended a
+ maximum of five redirections. Content developers should be aware
+ that there might be clients that implement such a fixed
+ limitation.
+ </t></list>
+</t>
+
+<section title="300 Multiple Choices" anchor="status.300">
+ <iref primary="true" item="300 Multiple Choices (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/>
+<t>
+ The requested resource corresponds to any one of a set of
+ representations, each with its own specific location, and agent-driven
+ negotiation information (&content-negotiation;) is being provided so that
+ the user (or user agent) can select a preferred representation and
+ redirect its request to that location.
+</t>
+<t>
+ Unless it was a HEAD request, the response &SHOULD; include an entity
+ containing a list of resource characteristics and location(s) from
+ which the user or user agent can choose the one most appropriate. The
+ entity format is specified by the media type given in the Content-Type
+ header field. Depending upon the format and the capabilities of
+ the user agent, selection of the most appropriate choice &MAY; be
+ performed automatically. However, this specification does not define
+ any standard for such automatic selection.
+</t>
+<t>
+ If the server has a preferred choice of representation, it &SHOULD;
+ include the specific URI for that representation in the Location
+ field; user agents &MAY; use the Location field value for automatic
+ redirection. This response is cacheable unless indicated otherwise.
+</t>
+</section>
+
+<section title="301 Moved Permanently" anchor="status.301">
+ <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/>
+<t>
+ The requested resource has been assigned a new permanent URI and any
+ future references to this resource &SHOULD; use one of the returned
+ URIs. Clients with link editing capabilities ought to automatically
+ re-link references to the Request-URI to one or more of the new
+ references returned by the server, where possible. This response is
+ cacheable unless indicated otherwise.
+</t>
+<t>
+ The new permanent URI &SHOULD; be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response &SHOULD; contain a short hypertext note with a hyperlink to
+ the new URI(s).
+</t>
+<t>
+ If the 301 status code is received in response to a request method
+ that is known to be "safe", as defined in <xref target="safe.methods"/>,
+ then the request MAY be automatically redirected by the user agent without
+ confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+ <list><t>
+ <x:h>Note:</x:h> When automatically redirecting a POST request after
+ receiving a 301 status code, some existing HTTP/1.0 user agents
+ will erroneously change it into a GET request.
+ </t></list>
+</t>
+</section>
+
+<section title="302 Found" anchor="status.302">
+ <iref primary="true" item="302 Found (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/>
+<t>
+ The requested resource resides temporarily under a different URI.
+ Since the redirection might be altered on occasion, the client &SHOULD;
+ continue to use the Request-URI for future requests. This response
+ is only cacheable if indicated by a Cache-Control or Expires header
+ field.
+</t>
+<t>
+ The temporary URI &SHOULD; be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response &SHOULD; contain a short hypertext note with a hyperlink to
+ the new URI(s).
+</t>
+<t>
+ If the 302 status code is received in response to a request method
+ that is known to be "safe", as defined in <xref target="safe.methods"/>,
+ then the request MAY be automatically redirected by the user agent without
+ confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+ <list><t>
+ <x:h>Note:</x:h> RFC 1945 and RFC 2068 specify that the client is not allowed
+ to change the method on the redirected request. However, most
+ existing user agent implementations treat 302 as if it were a 303
+ response, performing a GET on the Location field-value regardless
+ of the original request method. The status codes 303 and 307 have
+ been added for servers that wish to make unambiguously clear which
+ kind of reaction is expected of the client.
+ </t></list>
+</t>
+</section>
+
+<section title="303 See Other" anchor="status.303">
+ <iref primary="true" item="303 See Other (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="303 See Other" x:for-anchor=""/>
+<t>
+ The response to the request can be found under a different URI and
+ &SHOULD; be retrieved using a GET method on that resource. This method
+ exists primarily to allow the output of a POST-activated script to
+ redirect the user agent to a selected resource. The new URI is not a
+ substitute reference for the originally requested resource. The 303
+ response &MUST-NOT; be cached, but the response to the second
+ (redirected) request might be cacheable.
+</t>
+<t>
+ The different URI &SHOULD; be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response &SHOULD; contain a short hypertext note with a hyperlink to
+ the new URI(s).
+ <list><t>
+ <x:h>Note:</x:h> Many pre-HTTP/1.1 user agents do not understand the 303
+ status. When interoperability with such clients is a concern, the
+ 302 status code may be used instead, since most user agents react
+ to a 302 response as described here for 303.
+ </t></list>
+</t>
+</section>
+
+<section title="304 Not Modified" anchor="status.304">
+ <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
+<t>
+ If the client has performed a conditional GET request and access is
+ allowed, but the document has not been modified, the server &SHOULD;
+ respond with this status code. The 304 response &MUST-NOT; contain a
+ message-body, and thus is always terminated by the first empty line
+ after the header fields.
+</t>
+<t>
+ The response &MUST; include the following header fields:
+ <list style="symbols">
+ <t>Date, unless its omission is required by [clockless.origin.server.operation]</t>
+ </list>
+</t>
+<t>
+ If a clockless origin server obeys these rules, and proxies and
+ clients add their own Date to any response received without one (as
+ already specified by [RFC 2068], section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate
+ correctly.
+ <list style="symbols">
+ <t>ETag and/or Content-Location, if the header would have been sent
+ in a 200 response to the same request</t>
+ <t>Expires, Cache-Control, and/or Vary, if the field-value might
+ differ from that sent in any previous response for the same
+ variant</t>
+ </list>
+</t>
+<t>
+ If the conditional GET used a strong cache validator (see &caching;),
+ the response &SHOULD-NOT; include other entity-headers.
+ Otherwise (i.e., the conditional GET used a weak validator), the
+ response &MUST-NOT; include other entity-headers; this prevents
+ inconsistencies between cached entity-bodies and updated headers.
+</t>
+<t>
+ If a 304 response indicates an entity not currently cached, then the
+ cache &MUST; disregard the response and repeat the request without the
+ conditional.
+</t>
+<t>
+ If a cache uses a received 304 response to update a cache entry, the
+ cache &MUST; update the entry to reflect any new field values given in
+ the response.
+</t>
+</section>
+
+<section title="305 Use Proxy" anchor="status.305">
+ <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/>
+<t>
+ The requested resource &MUST; be accessed through the proxy given by
+ the Location field. The Location field gives the URI of the proxy.
+ The recipient is expected to repeat this single request via the
+ proxy. 305 responses &MUST; only be generated by origin servers.
+ <list><t>
+ <x:h>Note:</x:h> RFC 2068 was not clear that 305 was intended to redirect a
+ single request, and to be generated by origin servers only. Not
+ observing these limitations has significant security consequences.
+ </t></list>
+</t>
+</section>
+
+<section title="306 (Unused)" anchor="status.306">
+ <iref primary="true" item="306 (Unused) (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="306 (Unused)" x:for-anchor=""/>
+<t>
+ The 306 status code was used in a previous version of the
+ specification, is no longer used, and the code is reserved.
+</t>
+</section>
+
+<section title="307 Temporary Redirect" anchor="status.307">
+ <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/>
+<t>
+ The requested resource resides temporarily under a different URI.
+ Since the redirection &MAY; be altered on occasion, the client &SHOULD;
+ continue to use the Request-URI for future requests. This response
+ is only cacheable if indicated by a Cache-Control or Expires header
+ field.
+</t>
+<t>
+ The temporary URI &SHOULD; be given by the Location field in the
+ response. Unless the request method was HEAD, the entity of the
+ response &SHOULD; contain a short hypertext note with a hyperlink to
+ the new URI(s) , since many pre-HTTP/1.1 user agents do not
+ understand the 307 status. Therefore, the note &SHOULD; contain the
+ information necessary for a user to repeat the original request on
+ the new URI.
+</t>
+<t>
+ If the 307 status code is received in response to a request method
+ that is known to be "safe", as defined in <xref target="safe.methods"/>,
+ then the request MAY be automatically redirected by the user agent without
+ confirmation. Otherwise, the user agent &MUST-NOT; automatically redirect the
+ request unless it can be confirmed by the user, since this might
+ change the conditions under which the request was issued.
+</t>
+</section>
+</section>
+
+<section title="Client Error 4xx" anchor="status.4xx">
+<t>
+ The 4xx class of status code is intended for cases in which the
+ client seems to have erred. Except when responding to a HEAD request,
+ the server &SHOULD; include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. These status codes are applicable to any request method.
+ User agents &SHOULD; display any included entity to the user.
+</t>
+<t>
+ If the client is sending data, a server implementation using TCP
+ &SHOULD; be careful to ensure that the client acknowledges receipt of
+ the packet(s) containing the response, before the server closes the
+ input connection. If the client continues sending data to the server
+ after the close, the server's TCP stack will send a reset packet to
+ the client, which may erase the client's unacknowledged input buffers
+ before they can be read and interpreted by the HTTP application.
+</t>
+
+<section title="400 Bad Request" anchor="status.400">
+ <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/>
+<t>
+ The request could not be understood by the server due to malformed
+ syntax. The client &SHOULD-NOT; repeat the request without
+ modifications.
+</t>
+</section>
+
+<section title="401 Unauthorized" anchor="status.401">
+ <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/>
+<t>
+ The request requires user authentication. The response &MUST; include a
+ WWW-Authenticate header field (&header-www-authenticate;) containing a challenge
+ applicable to the requested resource. The client &MAY; repeat the
+ request with a suitable Authorization header field (&header-authorization;). If
+ the request already included Authorization credentials, then the 401
+ response indicates that authorization has been refused for those
+ credentials. If the 401 response contains the same challenge as the
+ prior response, and the user agent has already attempted
+ authentication at least once, then the user &SHOULD; be presented the
+ entity that was given in the response, since that entity might
+ include relevant diagnostic information. HTTP access authentication
+ is explained in "HTTP Authentication: Basic and Digest Access
+ Authentication" <xref target="RFC2617"/>.
+</t>
+</section>
+
+<section title="402 Payment Required" anchor="status.402">
+ <iref primary="true" item="402 Payment Required (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="402 Payment Required" x:for-anchor=""/>
+<t>
+ This code is reserved for future use.
+</t>
+</section>
+
+<section title="403 Forbidden" anchor="status.403">
+ <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/>
+<t>
+ The server understood the request, but is refusing to fulfill it.
+ Authorization will not help and the request &SHOULD-NOT; be repeated.
+ If the request method was not HEAD and the server wishes to make
+ public why the request has not been fulfilled, it &SHOULD; describe the
+ reason for the refusal in the entity. If the server does not wish to
+ make this information available to the client, the status code 404
+ (Not Found) can be used instead.
+</t>
+</section>
+
+<section title="404 Not Found" anchor="status.404">
+ <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
+<t>
+ The server has not found anything matching the Request-URI. No
+ indication is given of whether the condition is temporary or
+ permanent. The 410 (Gone) status code &SHOULD; be used if the server
+ knows, through some internally configurable mechanism, that an old
+ resource is permanently unavailable and has no forwarding address.
+ This status code is commonly used when the server does not wish to
+ reveal exactly why the request has been refused, or when no other
+ response is applicable.
+</t>
+</section>
+
+<section title="405 Method Not Allowed" anchor="status.405">
+ <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
+<t>
+ The method specified in the Request-Line is not allowed for the
+ resource identified by the Request-URI. The response &MUST; include an
+ Allow header containing a list of valid methods for the requested
+ resource.
+</t>
+</section>
+
+<section title="406 Not Acceptable" anchor="status.406">
+ <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/>
+<t>
+ The resource identified by the request is only capable of generating
+ response entities which have content characteristics not acceptable
+ according to the accept headers sent in the request.
+</t>
+<t>
+ Unless it was a HEAD request, the response &SHOULD; include an entity
+ containing a list of available entity characteristics and location(s)
+ from which the user or user agent can choose the one most
+ appropriate. The entity format is specified by the media type given
+ in the Content-Type header field. Depending upon the format and the
+ capabilities of the user agent, selection of the most appropriate
+ choice &MAY; be performed automatically. However, this specification
+ does not define any standard for such automatic selection.
+ <list><t>
+ <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
+ not acceptable according to the accept headers sent in the
+ request. In some cases, this may even be preferable to sending a
+ 406 response. User agents are encouraged to inspect the headers of
+ an incoming response to determine if it is acceptable.
+ </t></list>
+</t>
+<t>
+ If the response could be unacceptable, a user agent &SHOULD;
+ temporarily stop receipt of more data and query the user for a
+ decision on further actions.
+</t>
+</section>
+
+<section title="407 Proxy Authentication Required" anchor="status.407">
+ <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/>
+<t>
+ This code is similar to 401 (Unauthorized), but indicates that the
+ client must first authenticate itself with the proxy. The proxy &MUST;
+ return a Proxy-Authenticate header field (&header-proxy-authenticate;) containing a
+ challenge applicable to the proxy for the requested resource. The
+ client &MAY; repeat the request with a suitable Proxy-Authorization
+ header field (&header-proxy-authorization;). HTTP access authentication is explained
+ in "HTTP Authentication: Basic and Digest Access Authentication"
+ <xref target="RFC2617"/>.
+</t>
+</section>
+
+<section title="408 Request Timeout" anchor="status.408">
+ <iref primary="true" item="408 Request Timeout (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="408 Request Timeout" x:for-anchor=""/>
+<t>
+ The client did not produce a request within the time that the server
+ was prepared to wait. The client &MAY; repeat the request without
+ modifications at any later time.
+</t>
+</section>
+
+<section title="409 Conflict" anchor="status.409">
+ <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/>
+<t>
+ The request could not be completed due to a conflict with the current
+ state of the resource. This code is only allowed in situations where
+ it is expected that the user might be able to resolve the conflict
+ and resubmit the request. The response body &SHOULD; include enough
+ information for the user to recognize the source of the conflict.
+ Ideally, the response entity would include enough information for the
+ user or user agent to fix the problem; however, that might not be
+ possible and is not required.
+</t>
+<t>
+ Conflicts are most likely to occur in response to a PUT request. For
+ example, if versioning were being used and the entity being PUT
+ included changes to a resource which conflict with those made by an
+ earlier (third-party) request, the server might use the 409 response
+ to indicate that it can't complete the request. In this case, the
+ response entity would likely contain a list of the differences
+ between the two versions in a format defined by the response
+ Content-Type.
+</t>
+</section>
+
+<section title="410 Gone" anchor="status.410">
+ <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/>
+<t>
+ The requested resource is no longer available at the server and no
+ forwarding address is known. This condition is expected to be
+ considered permanent. Clients with link editing capabilities &SHOULD;
+ delete references to the Request-URI after user approval. If the
+ server does not know, or has no facility to determine, whether or not
+ the condition is permanent, the status code 404 (Not Found) &SHOULD; be
+ used instead. This response is cacheable unless indicated otherwise.
+</t>
+<t>
+ The 410 response is primarily intended to assist the task of web
+ maintenance by notifying the recipient that the resource is
+ intentionally unavailable and that the server owners desire that
+ remote links to that resource be removed. Such an event is common for
+ limited-time, promotional services and for resources belonging to
+ individuals no longer working at the server's site. It is not
+ necessary to mark all permanently unavailable resources as "gone" or
+ to keep the mark for any length of time -- that is left to the
+ discretion of the server owner.
+</t>
+</section>
+
+<section title="411 Length Required" anchor="status.411">
+ <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/>
+<t>
+ The server refuses to accept the request without a defined Content-Length.
+ The client &MAY; repeat the request if it adds a valid
+ Content-Length header field containing the length of the message-body
+ in the request message.
+</t>
+</section>
+
+<section title="412 Precondition Failed" anchor="status.412">
+ <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
+<t>
+ The precondition given in one or more of the request-header fields
+ evaluated to false when it was tested on the server. This response
+ code allows the client to place preconditions on the current resource
+ metainformation (header field data) and thus prevent the requested
+ method from being applied to a resource other than the one intended.
+</t>
+</section>
+
+<section title="413 Request Entity Too Large" anchor="status.413">
+ <iref primary="true" item="413 Request Entity Too Large (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="413 Request Entity Too Large" x:for-anchor=""/>
+<t>
+ The server is refusing to process a request because the request
+ entity is larger than the server is willing or able to process. The
+ server &MAY; close the connection to prevent the client from continuing
+ the request.
+</t>
+<t>
+ If the condition is temporary, the server &SHOULD; include a Retry-After
+ header field to indicate that it is temporary and after what
+ time the client &MAY; try again.
+</t>
+</section>
+
+<section title="414 Request-URI Too Long" anchor="status.414">
+ <iref primary="true" item="414 Request-URI Too Long (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="414 Request-URI Too Long" x:for-anchor=""/>
+<t>
+ The server is refusing to service the request because the Request-URI
+ is longer than the server is willing to interpret. This rare
+ condition is only likely to occur when a client has improperly
+ converted a POST request to a GET request with long query
+ information, when the client has descended into a URI "black hole" of
+ redirection (e.g., a redirected URI prefix that points to a suffix of
+ itself), or when the server is under attack by a client attempting to
+ exploit security holes present in some servers using fixed-length
+ buffers for reading or manipulating the Request-URI.
+</t>
+</section>
+
+<section title="415 Unsupported Media Type" anchor="status.415">
+ <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
+<t>
+ The server is refusing to service the request because the entity of
+ the request is in a format not supported by the requested resource
+ for the requested method.
+</t>
+</section>
+
+<section title="416 Requested Range Not Satisfiable" anchor="status.416">
+ <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/>
+<t>
+ The request included a Range request-header field (&header-range;) and none of
+ the range-specifier values in this field overlap the current extent
+ of the selected resource.
+</t>
+</section>
+
+<section title="417 Expectation Failed" anchor="status.417">
+ <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/>
+<t>
+ The expectation given in an Expect request-header field (see <xref target="header.expect"/>)
+ could not be met by this server, or, if the server is a proxy,
+ the server has unambiguous evidence that the request could not be met
+ by the next-hop server.
+</t>
+</section>
+</section>
+
+<section title="Server Error 5xx" anchor="status.5xx">
+<t>
+ Response status codes beginning with the digit "5" indicate cases in
+ which the server is aware that it has erred or is incapable of
+ performing the request. Except when responding to a HEAD request, the
+ server &SHOULD; include an entity containing an explanation of the
+ error situation, and whether it is a temporary or permanent
+ condition. User agents &SHOULD; display any included entity to the
+ user. These response codes are applicable to any request method.
+</t>
+
+<section title="500 Internal Server Error" anchor="status.500">
+ <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/>
+<t>
+ The server encountered an unexpected condition which prevented it
+ from fulfilling the request.
+</t>
+</section>
+
+<section title="501 Not Implemented" anchor="status.501">
+ <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="501 Not Implemented" x:for-anchor=""/>
+<t>
+ The server does not support the functionality required to fulfill the
+ request. This is the appropriate response when the server does not
+ recognize the request method and is not capable of supporting it for
+ any resource.
+</t>
+</section>
+
+<section title="502 Bad Gateway" anchor="status.502">
+ <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="502 Bad Gateway" x:for-anchor=""/>
+<t>
+ The server, while acting as a gateway or proxy, received an invalid
+ response from the upstream server it accessed in attempting to
+ fulfill the request.
+</t>
+</section>
+
+<section title="503 Service Unavailable" anchor="status.503">
+ <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/>
+<t>
+ The server is currently unable to handle the request due to a
+ temporary overloading or maintenance of the server. The implication
+ is that this is a temporary condition which will be alleviated after
+ some delay. If known, the length of the delay &MAY; be indicated in a
+ Retry-After header. If no Retry-After is given, the client &SHOULD;
+ handle the response as it would for a 500 response.
+ <list><t>
+ <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
+ server must use it when becoming overloaded. Some servers may wish
+ to simply refuse the connection.
+ </t></list>
+</t>
+</section>
+
+<section title="504 Gateway Timeout" anchor="status.504">
+ <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout" x:for-anchor=""/>
+<t>
+ The server, while acting as a gateway or proxy, did not receive a
+ timely response from the upstream server specified by the URI (e.g.
+ HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
+ to access in attempting to complete the request.
+ <list><t>
+ <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to
+ return 400 or 500 when DNS lookups time out.
+ </t></list>
+</t>
+</section>
+
+<section title="505 HTTP Version Not Supported" anchor="status.505">
+ <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/>
+ <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/>
+<t>
+ The server does not support, or refuses to support, the HTTP protocol
+ version that was used in the request message. The server is
+ indicating that it is unable or unwilling to complete the request
+ using the same major version as the client, as described in &http-version;,
+ other than with this error message. The response &SHOULD; contain
+ an entity describing why that version is not supported and what other
+ protocols are supported by that server.
+</t>
+
+</section>
+</section>
+</section>
+
+
+<section title="Header Field Definitions" anchor="header.fields">
+<t>
+ 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>
+
+<section title="Allow" anchor="header.allow">
+ <iref primary="true" item="Allow header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Allow" x:for-anchor=""/>
+<t>
+ The Allow entity-header field lists the set of methods supported
+ by the resource identified by the Request-URI. The purpose of this
+ field is strictly to inform the recipient of valid methods
+ associated with the resource. An Allow header field &MUST; be
+ present in a 405 (Method Not Allowed) response.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
+ Allow = "Allow" ":" #Method
+</artwork></figure>
+<t>
+ Example of use:
+</t>
+<figure><artwork type="example">
+ Allow: GET, HEAD, PUT
+</artwork></figure>
+<t>
+ This field cannot prevent a client from trying other methods.
+ However, the indications given by the Allow header field value
+ &SHOULD; be followed. The actual set of allowed methods is defined
+ by the origin server at the time of each request.
+</t>
+<t>
+ The Allow header field &MAY; be provided with a PUT request to
+ recommend the methods to be supported by the new or modified
+ resource. The server is not required to support these methods and
+ &SHOULD; include an Allow header in the response giving the actual
+ supported methods.
+</t>
+<t>
+ A proxy &MUST-NOT; modify the Allow header field even if it does not
+ understand all the methods specified, since the user agent might
+ have other means of communicating with the origin server.
+</t>
+</section>
+
+<section title="Expect" anchor="header.expect">
+ <iref primary="true" item="Expect header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Expect" x:for-anchor=""/>
+<t>
+ The Expect request-header field is used to indicate that particular
+ server behaviors are required by the client.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expectation-extension"/><iref primary="true" item="Grammar" subitem="expect-params"/>
+ Expect = "Expect" ":" 1#expectation
+
+ expectation = "100-continue" | expectation-extension
+ expectation-extension = token [ "=" ( token | quoted-string )
+ *expect-params ]
+ expect-params = ";" token [ "=" ( token | quoted-string ) ]
+</artwork></figure>
+<t>
+ A server that does not understand or is unable to comply with any of
+ the expectation values in the Expect field of a request &MUST; respond
+ with appropriate error status. The server &MUST; respond with a 417
+ (Expectation Failed) status if any of the expectations cannot be met
+ or, if there are other problems with the request, some other 4xx
+ status.
+</t>
+<t>
+ This header field is defined with extensible syntax to allow for
+ future extensions. If a server receives a request containing an
+ Expect field that includes an expectation-extension that it does not
+ support, it &MUST; respond with a 417 (Expectation Failed) status.
+</t>
+<t>
+ Comparison of expectation values is case-insensitive for unquoted
+ tokens (including the 100-continue token), and is case-sensitive for
+ quoted-string expectation-extensions.
+</t>
+<t>
+ The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy &MUST;
+ return a 417 (Expectation Failed) status if it receives a request
+ with an expectation that it cannot meet. However, the Expect
+ request-header itself is end-to-end; it &MUST; be forwarded if the
+ request is forwarded.
+</t>
+<t>
+ Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
+ Expect header.
+</t>
+<t>
+ See &use100; for the use of the 100 (continue) status.
+</t>
+</section>
+
+<section title="From" anchor="header.from">
+ <iref primary="true" item="From header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="From" x:for-anchor=""/>
+<t>
+ The From request-header field, if given, &SHOULD; contain an Internet
+ e-mail address for the human user who controls the requesting user
+ agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
+ in RFC 822 <xref target="RFC822"/> as updated by RFC 1123 <xref target="RFC1123"/>:
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
+ From = "From" ":" mailbox
+</artwork></figure>
+<t>
+ An example is:
+</t>
+<figure><artwork type="example">
+ From: webmaster@w3.org
+</artwork></figure>
+<t>
+ This header field &MAY; be used for logging purposes and as a means for
+ identifying the source of invalid or unwanted requests. It &SHOULD-NOT;
+ be used as an insecure form of access protection. The interpretation
+ of this field is that the request is being performed on behalf of the
+ person given, who accepts responsibility for the method performed. In
+ particular, robot agents &SHOULD; include this header so that the
+ person responsible for running the robot can be contacted if problems
+ occur on the receiving end.
+</t>
+<t>
+ The Internet e-mail address in this field &MAY; be separate from the
+ Internet host which issued the request. For example, when a request
+ is passed through a proxy the original issuer's address &SHOULD; be
+ used.
+</t>
+<t>
+ The client &SHOULD-NOT; send the From header field without the user's
+ approval, as it might conflict with the user's privacy interests or
+ their site's security policy. It is strongly recommended that the
+ user be able to disable, enable, and modify the value of this field
+ at any time prior to a request.
+</t>
+</section>
+
+<section title="Location" anchor="header.location">
+ <iref primary="true" item="Location header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Location" x:for-anchor=""/>
+<t>
+ The Location response-header field is used to redirect the recipient
+ to a location other than the Request-URI for completion of the
+ request or identification of a new resource. For 201 (Created)
+ responses, the Location is that of the new resource which was created
+ by the request. For 3xx responses, the location &SHOULD; indicate the
+ server's preferred URI for automatic redirection to the resource. The
+ field value consists of a single absolute URI.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
+ Location = "Location" ":" absoluteURI [ "#" fragment ]
+</artwork></figure>
+<t>
+ An example is:
+</t>
+<figure><artwork type="example">
+ Location: http://www.w3.org/pub/WWW/People.html
+</artwork></figure>
+<t>
+ <list><t>
+ <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
+ from Location in that the Content-Location identifies the original
+ location of the entity enclosed in the request. It is therefore
+ possible for a response to contain header fields for both Location
+ and Content-Location.
+ </t></list>
+</t>
+</section>
+
+<section title="Max-Forwards" anchor="header.max-forwards">
+ <iref primary="true" item="Max-Forwards header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Max-Forwards" x:for-anchor=""/>
+<t>
+ The Max-Forwards request-header field provides a mechanism with the
+ TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the
+ number of proxies or gateways that can forward the request to the
+ next inbound server. This can be useful when the client is attempting
+ to trace a request chain which appears to be failing or looping in
+ mid-chain.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
+ Max-Forwards = "Max-Forwards" ":" 1*DIGIT
+</artwork></figure>
+<t>
+ The Max-Forwards value is a decimal integer indicating the remaining
+ number of times this request message may be forwarded.
+</t>
+<t>
+ Each proxy or gateway recipient of a TRACE or OPTIONS request
+ containing a Max-Forwards header field &MUST; check and update its
+ value prior to forwarding the request. If the received value is zero
+ (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
+ respond as the final recipient. If the received Max-Forwards value is
+ greater than zero, then the forwarded message &MUST; contain an updated
+ Max-Forwards field with a value decremented by one (1).
+</t>
+<t>
+ The Max-Forwards header field &MAY; be ignored for all other methods
+ defined by this specification and for any extension methods for which
+ it is not explicitly referred to as part of that method definition.
+</t>
+</section>
+
+<section title="Referer" anchor="header.referer">
+ <iref primary="true" item="Referer header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Referer" x:for-anchor=""/>
+<t>
+ The Referer[sic] request-header field allows the client to specify,
+ for the server's benefit, the address (URI) of the resource from
+ which the Request-URI was obtained (the "referrer", although the
+ header field is misspelled.) The Referer request-header allows a
+ server to generate lists of back-links to resources for interest,
+ logging, optimized caching, etc. It also allows obsolete or mistyped
+ links to be traced for maintenance. The Referer field &MUST-NOT; be
+ sent if the Request-URI was obtained from a source that does not have
+ its own URI, such as input from the user keyboard.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
+ Referer = "Referer" ":" ( absoluteURI | relativeURI )
+</artwork></figure>
+<t>
+ Example:
+</t>
+<figure><artwork type="example">
+ Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+</artwork></figure>
+<t>
+ If the field value is a relative URI, it &SHOULD; be interpreted
+ relative to the Request-URI. The URI &MUST-NOT; include a fragment. See
+ <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
+</t>
+</section>
+
+<section title="Retry-After" anchor="header.retry-after">
+ <iref primary="true" item="Retry-After header" x:for-anchor=""/>
+ <iref primary="true" item="Headers" subitem="Retry-After" x:for-anchor=""/>
+<t>
+ The Retry-After response-header field can be used with a 503 (Service
+ Unavailable) response to indicate how long the service is expected to
+ be unavailable to the requesting client. This field &MAY; also be used
+ with any 3xx (Redirection) response to indicate the minimum time the
+ user-agent is asked wait before issuing the redirected request. The
[... 442 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@labs.apache.org
For additional commands, e-mail: commits-help@labs.apache.org