Changeset 1630
- Timestamp:
- 28/03/12 16:18:53 (10 years ago)
- Location:
- draft-ietf-httpbis/experiment
- Files:
-
- 9 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/experiment/httpbis.abnf
r1627 r1630 135 135 field-value = *( field-content / obs-fold ) 136 136 first-byte-pos = 1*DIGIT 137 ; bar UNDEFINED138 foo = bar139 137 header-field = field-name ":" OWS field-value BWS 140 138 hour = 2DIGIT … … 220 218 te-ext = OWS ";" OWS token [ "=" word ] 221 219 te-params = OWS ";" OWS "q=" qvalue *te-ext 220 this = <part does not have an ABNF anymore> 222 221 time-of-day = hour ":" minute ":" second 223 222 token = 1*tchar … … 287 286 ; Warning defined but not used 288 287 ; chunked-body defined but not used 289 ; foo defined but not used290 288 ; http-URI defined but not used 291 289 ; https-URI defined but not used 292 290 ; special defined but not used 291 ; this defined but not used -
draft-ietf-httpbis/experiment/p1-messaging.html
r1629 r1630 757 757 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 758 758 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 759 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title=" ERROR: Anchor 'differences.between.http.and.mime' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'differences.between.http.and.mime' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the differences between HTTP and MIME messages).759 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the differences between HTTP and MIME messages). 760 760 </p> 761 761 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented … … 910 910 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 911 911 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 912 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title=" ERROR: Anchor 'status.203' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.203' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.912 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 913 913 </p> 914 914 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1078 1078 </p> 1079 1079 <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1080 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title=" ERROR: Anchor 'status.code.and.reason.phrase' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.code.and.reason.phrase' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1080 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1081 1081 </p> 1082 1082 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1174 1174 </div> 1175 1175 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1176 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title=" ERROR: Anchor 'methods' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'methods' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1176 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1177 1177 </p> 1178 1178 <div id="rfc.iref.r.6"></div> … … 1189 1189 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1190 1190 it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a 501 (Not Implemented) status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1191 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title=" ERROR: Anchor 'status.414' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.414' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1191 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1192 1192 </p> 1193 1193 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. … … 1199 1199 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status-code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1200 1200 </pre><div id="status-code"> 1201 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title=" ERROR: Anchor 'status.code.and.reason.phrase' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.code.and.reason.phrase' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations1201 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1202 1202 for new status codes. 1203 1203 </p> … … 1223 1223 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1224 1224 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title=" ERROR: Anchor 'header.date' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.date' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1226 1226 </p> 1227 1227 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1231 1231 them. 1232 1232 </p> 1233 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title=" ERROR: Anchor 'considerations.for.creating.header.fields' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'considerations.for.creating.header.fields' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1233 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1234 1234 </p> 1235 1235 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1418 1418 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1419 1419 </p> 1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title=" ERROR: Anchor 'content.codings' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'content.codings' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1421 1421 </p> 1422 1422 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to … … 1725 1725 </p> 1726 1726 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title=" ERROR: Anchor 'content.negotiation' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'content.negotiation' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1728 1728 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 1729 1729 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 1826 1826 </p> 1827 1827 <div id="authority-form"> 1828 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title=" ERROR: Anchor 'CONNECT' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'CONNECT' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1828 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1829 1829 </p> 1830 1830 </div> 1831 1831 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1832 1832 </pre><div id="asterisk-form"> 1833 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title=" ERROR: Anchor 'OPTIONS' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'OPTIONS' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1833 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1834 1834 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1835 1835 </p> … … 1992 1992 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1993 1993 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1994 see <a href="p2-semantics.html#status.1xx" title=" ERROR: Anchor 'status.1xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.1xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.1994 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 1995 1995 </p> 1996 1996 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. … … 2137 2137 <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2138 2138 </p> 2139 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title=" ERROR: Anchor 'idempotent.methods' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'idempotent.methods' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2139 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2140 2140 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2141 2141 </p> … … 2167 2167 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2168 2168 <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2169 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title=" ERROR: Anchor 'idempotent.methods' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'idempotent.methods' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2169 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2170 2170 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2171 2171 </p> … … 2180 2180 </p> 2181 2181 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2182 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title=" ERROR: Anchor 'status.100' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.100' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2182 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2183 2183 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2184 2184 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2187 2187 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2188 2188 <ul> 2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="E RROR: Anchor 'header.expect' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.expect' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="E RROR: Anchor 'header.expect' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'header.expect' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.3</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2192 2192 </li> 2193 2193 </ul> … … 2233 2233 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2234 2234 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2235 1xx responses (see <a href="p2-semantics.html#status.1xx" title=" ERROR: Anchor 'status.1xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.1xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2235 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2236 2236 </li> 2237 2237 </ul> … … 2270 2270 </p> 2271 2271 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2272 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title=" ERROR: Anchor 'status.3xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.3xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2272 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2273 2273 </p> 2274 2274 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 2534 2534 <li>Pointer to specification text</li> 2535 2535 </ul> 2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title=" ERROR: Anchor 'content.codings' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'content.codings' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2537 2537 </p> 2538 2538 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 2694 2694 that most implementations will choose substantially higher limits. 2695 2695 </p> 2696 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title=" ERROR: Anchor 'status.414' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.414' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="ERROR: Anchor 'status.4xx' not found in p2-semantics.xml.">Appendix ERROR: Anchor 'status.4xx' in Part2 not found in source file 'p2-semantics.xml'.</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2696 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2697 2697 </p> 2698 2698 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 3746 3746 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3747 3747 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a>, <a href="#rfc.xref.Part2.18">6.4.3</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.5</a>, <a href="#rfc.xref.Part2.23">7.4</a>, <a href="#rfc.xref.Part2.24">8.6</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3748 <li><em> Appendix </em> <a href="#rfc.xref.Part2.1">1</a></li>3749 <li><em> Appendix </em> <a href="#rfc.xref.Part2.2">2.3</a></li>3750 <li><em> Appendix </em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>3751 <li><em> Appendix </em> <a href="#rfc.xref.Part2.4">3.1.1</a></li>3752 <li><em> Appendix </em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li>3753 <li><em> Appendix </em> <a href="#rfc.xref.Part2.7">3.2</a></li>3754 <li><em> Appendix </em> <a href="#rfc.xref.Part2.8">3.2</a></li>3755 <li><em> Appendix </em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>3756 <li><em> Appendix </em> <a href="#rfc.xref.Part2.10">4.3.1</a></li>3757 <li><em> Appendix </em> <a href="#rfc.xref.Part2.12">5.3</a></li>3758 <li><em> Appendix </em> <a href="#rfc.xref.Part2.13">5.3</a></li>3759 <li><em> Appendix </em> <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>3760 <li><em> Appendix </em> <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li>3761 <li><em> Appendix </em> <a href="#rfc.xref.Part2.18">6.4.3</a></li>3762 <li><em> Appendix </em> <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>3763 <li><em> Appendix </em> <a href="#rfc.xref.Part2.22">6.5</a></li>3764 <li><em>Appendix </em> <a href="#rfc.xref.Part2.25">8.6</a></li>3748 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3749 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li> 3750 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3751 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.12">5.3</a></li> 3752 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3753 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li> 3754 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li> 3755 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.18">6.4.3</a></li> 3756 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3757 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.22">6.5</a></li> 3758 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.25">8.6</a></li> 3759 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li> 3760 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li> 3761 <li><em>Section 9</em> <a href="#rfc.xref.Part2.10">4.3.1</a></li> 3762 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3763 <li><em>Section 10.3</em> <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li> 3764 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.1">1</a></li> 3765 3765 </ul> 3766 3766 </li> -
draft-ietf-httpbis/experiment/p2-semantics.html
r1629 r1630 895 895 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 896 896 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 897 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 897 898 </pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 898 899 <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p> 899 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 900 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 901 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 902 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 900 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 901 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 902 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 903 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a>> 904 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 903 905 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="methods" href="#methods">Methods</a></h1> 904 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.906 <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 905 907 </p> 906 908 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> … … 953 955 to a single application, so that this is clear. 954 956 </p> 955 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message957 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message 956 958 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 957 959 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 973 975 to HTTP might use the OPTIONS body to make more detailed queries on the server. 974 976 </p> 975 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource.977 <p id="rfc.section.2.3.1.p.4">If the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. 976 978 Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" 977 979 type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be … … 1136 1138 </p> 1137 1139 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1138 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1. 18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1140 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1139 1141 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1140 1142 infinite loop. 1141 1143 </p> 1142 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1144 <p id="rfc.section.2.3.7.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1143 1145 </p> 1144 1146 <div id="rfc.iref.c.2"></div> … … 1148 1150 its behavior to blind forwarding of packets until the connection is closed. 1149 1151 </p> 1150 <p id="rfc.section.2.3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1152 <p id="rfc.section.2.3.8.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1151 1153 For example, 1152 1154 </p> … … 1184 1186 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 1185 1187 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 1186 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.1188 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 1187 1189 </p> 1188 1190 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> … … 1192 1194 with "X-" if they are to be registered (either immediately or in the future). 1193 1195 </p> 1194 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters1196 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 3.2.5</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 1195 1197 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 1196 1198 </p> 1197 1199 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 1198 1200 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 1199 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1201 quoted-string ABNF production (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1200 1202 </p> 1201 1203 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 1215 1217 <ul> 1216 1218 <li> 1217 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1219 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1218 1220 </p> 1219 1221 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible … … 1231 1233 </li> 1232 1234 <li> 1233 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1235 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1234 1236 </p> 1235 1237 </li> … … 1242 1244 </li> 1243 1245 <li> 1244 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1246 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1245 1247 </p> 1246 1248 </li> … … 1293 1295 <tr> 1294 1296 <td class="left">Host</td> 1295 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1297 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1296 1298 </tr> 1297 1299 <tr> … … 1333 1335 <tr> 1334 1336 <td class="left">TE</td> 1335 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1. 28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>1337 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 1336 1338 </tr> 1337 1339 <tr> … … 1344 1346 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1345 1347 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1346 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1348 status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1347 1349 </p> 1348 1350 <div id="rfc.table.u.2"> … … 1691 1693 <p id="rfc.section.4.3.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1692 1694 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1693 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1695 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1694 1696 </p> 1695 1697 <div id="rfc.iref.25"></div> 1696 1698 <div id="rfc.iref.s.4"></div> 1697 1699 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1698 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1700 <p id="rfc.section.4.3.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1699 1701 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1700 1702 </p> … … 1749 1751 <div id="rfc.iref.s.8"></div> 1750 1752 <h3 id="rfc.section.4.4.4"><a href="#rfc.section.4.4.4">4.4.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1751 <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1753 <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1752 1754 </p> 1753 1755 <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1784 1786 another input action. 1785 1787 </p> 1786 <p id="rfc.section.4.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1788 <p id="rfc.section.4.4.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1787 1789 </p> 1788 1790 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 2044 2046 <div id="rfc.iref.s.32"></div> 2045 2047 <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2046 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2048 <p id="rfc.section.4.6.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.5</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2047 2049 </p> 2048 2050 <div id="rfc.figure.u.8"></div> … … 2105 2107 <p id="rfc.section.4.7.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2106 2108 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2107 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2109 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2108 2110 </p> 2109 2111 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="representation" href="#representation">Representation</a></h1> … … 2112 2114 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#payload" title="Payload">Section 7</a>. 2113 2115 </p> 2114 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied2116 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied 2115 2117 to ensure safe and proper transfer of the message. 2116 2118 </p> … … 2118 2120 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 2119 2121 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 2120 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following2122 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 2121 2123 rules are used (with the first applicable one being selected): 2122 2124 </p> … … 2269 2271 </p> 2270 2272 <ul class="empty"> 2271 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2273 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2272 2274 </li> 2273 2275 </ul> … … 2275 2277 </p> 2276 2278 <ul class="empty"> 2277 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2279 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2278 2280 </li> 2279 2281 </ul> … … 2281 2283 </p> 2282 2284 <ul class="empty"> 2283 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2285 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2284 2286 </li> 2285 2287 </ul> … … 2293 2295 <li>Pointer to specification text</li> 2294 2296 </ul> 2295 <p id="rfc.section.6.4.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.4 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2297 <p id="rfc.section.6.4.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2296 2298 </p> 2297 2299 <p id="rfc.section.6.4.1.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.3"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 2311 2313 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#rule.parameter" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a> 2312 2314 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#core.rules" class="smpl">token</a> 2313 <a href="#rule.parameter" class="smpl">value</a> = word2315 <a href="#rule.parameter" class="smpl">value</a> = <a href="#core.rules" class="smpl">word</a> 2314 2316 </pre><p id="rfc.section.6.5.p.5">The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, 2315 2317 depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing … … 2393 2395 <tr> 2394 2396 <td class="left">Content-Length</td> 2395 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>2397 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 2396 2398 </tr> 2397 2399 <tr> … … 2403 2405 </div> 2404 2406 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 2405 <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure2407 <p id="rfc.section.7.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure 2406 2408 safe and proper transfer of the message. 2407 2409 </p> … … 2657 2659 </p> 2658 2660 <ul class="empty"> 2659 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2661 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2660 2662 </li> 2661 2663 </ul> … … 2769 2771 <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2770 2772 <p id="rfc.section.10.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2771 <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2773 <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2772 2774 identifying the application. 2773 2775 </p> … … 2775 2777 </pre><p id="rfc.section.10.9.p.4">Example:</p> 2776 2778 <div id="rfc.figure.u.42"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2777 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2779 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2778 2780 </p> 2779 2781 <div class="note" id="rfc.section.10.9.p.7"> … … 2791 2793 user agent limitations. 2792 2794 </p> 2793 <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2795 <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2794 2796 for identifying the application. 2795 2797 </p> … … 2818 2820 / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> ) 2819 2821 ) *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 2820 <a href="#header.accept" class="smpl">accept-params</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" qvalue*( <a href="#header.accept" class="smpl">accept-ext</a> )2821 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" word]2822 <a href="#header.accept" class="smpl">accept-params</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> *( <a href="#header.accept" class="smpl">accept-ext</a> ) 2823 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ] 2822 2824 </pre><p id="rfc.section.10.11.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 2823 2825 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. … … 2915 2917 </p> 2916 2918 <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 2917 [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" qvalue] )2919 [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2918 2920 </pre><p id="rfc.section.10.12.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 2919 2921 example is … … 2935 2937 no encoding is preferred. 2936 2938 </p> 2937 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" qvalue] )2939 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2938 2940 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 2939 2941 </pre><p id="rfc.section.10.13.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1. … … 2979 2981 </p> 2980 2982 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 2981 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" qvalue] )2983 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2982 2984 <a href="#header.accept-language" class="smpl">language-range</a> = 2983 2985 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> … … 3070 3072 </p> 3071 3073 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.60"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 3072 </pre><p id="rfc.section.10.17.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1. 49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME3074 </pre><p id="rfc.section.10.17.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 3073 3075 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 3074 3076 </p> … … 3590 3592 <td class="left">compress</td> 3591 3593 <td class="left">UNIX "compress" program method</td> 3592 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.5 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>3594 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 3593 3595 </td> 3594 3596 </tr> … … 3597 3599 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 3598 3600 </td> 3599 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>3601 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 3600 3602 </td> 3601 3603 </tr> … … 3603 3605 <td class="left">gzip</td> 3604 3606 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 3605 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>3607 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 3606 3608 </td> 3607 3609 </tr> … … 3698 3700 </p> 3699 3701 <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 3700 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.3702 <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 3701 3703 </p> 3702 3704 <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References … … 3955 3957 </p> 3956 3958 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 3957 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.3959 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.56"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 3958 3960 </p> 3959 3961 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 4010 4012 </p> 4011 4013 <p id="rfc.section.C.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 4012 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.5 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>)4014 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.57"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 10.9</a>) 4013 4015 </p> 4014 4016 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>) … … 4068 4070 4069 4071 <a href="#mime-version" class="smpl">MIME-Version</a> = 1*DIGIT "." 1*DIGIT 4070 4071 4072 <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT 4072 4073 … … 4074 4075 4075 4076 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in [Part1], Section 3.2.1> 4076 4077 4077 <a href="#header.referer" class="smpl">Referer</a> = absolute-URI / partial-URI 4078 4078 <a href="#header.retry-after" class="smpl">Retry-After</a> = HTTP-date / delta-seconds … … 4081 4081 4082 4082 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in [Part1], Section 2.7> 4083 4084 4083 <a href="#header.user-agent" class="smpl">User-Agent</a> = product *( RWS ( product / comment ) ) 4085 4084 4086 4085 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in [Part1], Section 2.7> 4087 4088 4086 <a href="#header.accept" class="smpl">accept-ext</a> = OWS ";" OWS token [ "=" word ] 4089 4087 <a href="#header.accept" class="smpl">accept-params</a> = OWS ";" OWS "q=" qvalue *accept-ext 4090 4091 4088 <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = day-name SP date3 SP time-of-day SP year 4092 4089 <a href="#rule.parameter" class="smpl">attribute</a> = token 4093 4090 4094 4091 <a href="#rule.charset" class="smpl">charset</a> = token 4095 4096 4092 <a href="#header.accept-encoding" class="smpl">codings</a> = content-coding / "identity" / "*" 4097 4098 4093 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in [Part1], Section 3.2.4> 4099 4094 <a href="#content.codings" class="smpl">content-coding</a> = token 4100 4095 4101 4096 <a href="#obsolete.date.formats" class="smpl">date1</a> = day SP month SP year 4102 4103 4097 <a href="#obsolete.date.formats" class="smpl">date2</a> = day "-" month "-" 2DIGIT 4104 4105 4098 <a href="#obsolete.date.formats" class="smpl">date3</a> = month SP ( 2DIGIT / ( SP DIGIT ) ) 4106 4099 <a href="#preferred.date.format" class="smpl">day</a> = 2DIGIT … … 4122 4115 4123 4116 <a href="#header.expect" class="smpl">expect-name</a> = token 4124 4125 4117 <a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ] 4126 4127 4118 <a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string 4128 4119 <a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ … … 4132 4123 4133 4124 <a href="#header.accept-language" class="smpl">language-range</a> = <language-range, defined in [RFC4647], Section 2.1> 4134 4135 4125 <a href="#language.tags" class="smpl">language-tag</a> = <Language-Tag, defined in [RFC5646], Section 2.1> 4136 4126 4137 4127 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in [RFC5322], Section 3.4> 4138 4139 4128 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 4140 4129 ";" OWS parameter ) … … 4156 4145 4157 4146 <a href="#obsolete.date.formats" class="smpl">obs-date</a> = rfc850-date / asctime-date 4158 4159 4147 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in [Part1], Section 3.2.4> 4160 4148 4161 4149 <a href="#rule.parameter" class="smpl">parameter</a> = attribute "=" value 4162 4163 4150 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.7> 4164 4165 4151 <a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ] 4166 4152 <a href="#product.tokens" class="smpl">product-version</a> = token 4167 4153 4168 4154 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 3.2.4> 4155 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in [Part1], Section 4.3.1> 4169 4156 4170 4157 <a href="#status.code.and.reason.phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text ) 4171 4172 4158 <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT 4173 4174 4159 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT 4175 4160 4176 4161 <a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT 4177 4178 4162 <a href="#status.code.and.reason.phrase" class="smpl">status-code</a> = 3DIGIT 4179 4180 4163 <a href="#media.types" class="smpl">subtype</a> = token 4181 4164 4182 4165 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second 4183 4184 4166 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 3.2.4> 4185 4186 4167 <a href="#media.types" class="smpl">type</a> = token 4187 4168 4188 4169 <a href="#rule.parameter" class="smpl">value</a> = word 4189 4170 4171 <a href="#core.rules" class="smpl">word</a> = <word, defined in [Part1], Section 3.2.4> 4172 4190 4173 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 4191 4174 </pre> <div id="rfc.figure.u.66"></div> 4192 <p>ABNF diagnostics:</p><pre class="inline">; qvalue UNDEFINED 4193 ; word UNDEFINED 4194 ; Accept defined but not used 4175 <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used 4195 4176 ; Accept-Charset defined but not used 4196 4177 ; Accept-Encoding defined but not used … … 4997 4978 </li> 4998 4979 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4999 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3. 2</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.8</a>, <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.2</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.30">4.3.1</a>, <a href="#rfc.xref.Part1.31">4.3.2</a>, <a href="#rfc.xref.Part1.32">4.4.4</a>, <a href="#rfc.xref.Part1.33">4.4.6</a>, <a href="#rfc.xref.Part1.34">4.6.15</a>, <a href="#rfc.xref.Part1.35">4.7.6</a>, <a href="#rfc.xref.Part1.36">5</a>, <a href="#rfc.xref.Part1.37">5.1</a>, <a href="#rfc.xref.Part1.38">6.4</a>, <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.41">6.4.1</a>, <a href="#rfc.xref.Part1.42">6.4.1</a>, <a href="#rfc.xref.Part1.43">7.1</a>, <a href="#rfc.xref.Part1.44">7.2</a>, <a href="#rfc.xref.Part1.45">10.3</a>, <a href="#rfc.xref.Part1.46">10.9</a>, <a href="#rfc.xref.Part1.47">10.9</a>, <a href="#rfc.xref.Part1.48">10.10</a>, <a href="#rfc.xref.Part1.49">10.17</a>, <a href="#rfc.xref.Part1.50">11.4</a>, <a href="#rfc.xref.Part1.51">11.4</a>, <a href="#rfc.xref.Part1.52">11.4</a>, <a href="#rfc.xref.Part1.53">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.54">A.6</a>, <a href="#rfc.xref.Part1.55">C</a><ul>4980 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">1.3.2</a>, <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.18">2.2.1</a>, <a href="#rfc.xref.Part1.19">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.7</a>, <a href="#rfc.xref.Part1.22">2.3.8</a>, <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.1</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.33">4.3.2</a>, <a href="#rfc.xref.Part1.34">4.4.4</a>, <a href="#rfc.xref.Part1.35">4.4.6</a>, <a href="#rfc.xref.Part1.36">4.6.15</a>, <a href="#rfc.xref.Part1.37">4.7.6</a>, <a href="#rfc.xref.Part1.38">5</a>, <a href="#rfc.xref.Part1.39">5.1</a>, <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.42">6.4</a>, <a href="#rfc.xref.Part1.43">6.4.1</a>, <a href="#rfc.xref.Part1.44">6.4.1</a>, <a href="#rfc.xref.Part1.45">7.1</a>, <a href="#rfc.xref.Part1.46">7.2</a>, <a href="#rfc.xref.Part1.47">10.3</a>, <a href="#rfc.xref.Part1.48">10.9</a>, <a href="#rfc.xref.Part1.49">10.9</a>, <a href="#rfc.xref.Part1.50">10.10</a>, <a href="#rfc.xref.Part1.51">10.17</a>, <a href="#rfc.xref.Part1.52">11.4</a>, <a href="#rfc.xref.Part1.53">11.4</a>, <a href="#rfc.xref.Part1.54">11.4</a>, <a href="#rfc.xref.Part1.55">13</a>, <a href="#Part1"><b>14.1</b></a>, <a href="#rfc.xref.Part1.56">A.6</a>, <a href="#rfc.xref.Part1.57">C</a><ul> 5000 4981 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.3</a></li> 5001 4982 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 5002 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.3 2">4.4.4</a></li>5003 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.3 5">4.7.6</a></li>5004 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.1 1">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a></li>4983 <li><em>Section 2.3</em> <a href="#rfc.xref.Part1.34">4.4.4</a></li> 4984 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.37">4.7.6</a></li> 4985 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.16">1.3.2</a></li> 5005 4986 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a></li> 5006 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.21">3</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.46">10.9</a>, <a href="#rfc.xref.Part1.48">10.10</a></li> 5007 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.23">3.1</a></li> 5008 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 5009 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.33">4.4.6</a>, <a href="#rfc.xref.Part1.36">5</a>, <a href="#rfc.xref.Part1.44">7.2</a></li> 5010 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.54">A.6</a></li> 5011 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.43">7.1</a></li> 5012 <li><em>Section 4</em> <a href="#rfc.xref.Part1.41">6.4.1</a></li> 5013 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.26">3.1</a></li> 5014 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.38">6.4</a>, <a href="#rfc.xref.Part1.50">11.4</a></li> 5015 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.42">6.4.1</a></li> 5016 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.51">11.4</a></li> 5017 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.52">11.4</a></li> 5018 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.28">3.2</a></li> 5019 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.17">2.3.1</a>, <a href="#rfc.xref.Part1.20">2.3.8</a></li> 5020 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.27">3.2</a></li> 5021 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.29">3.3</a>, <a href="#rfc.xref.Part1.37">5.1</a>, <a href="#rfc.xref.Part1.49">10.17</a></li> 5022 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.25">3.1</a></li> 5023 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.18">2.3.7</a>, <a href="#rfc.xref.Part1.47">10.9</a>, <a href="#rfc.xref.Part1.55">C</a></li> 5024 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.30">4.3.1</a>, <a href="#rfc.xref.Part1.45">10.3</a></li> 5025 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.31">4.3.2</a>, <a href="#rfc.xref.Part1.34">4.6.15</a></li> 5026 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.19">2.3.7</a></li> 5027 <li><em>Section 9</em> <a href="#rfc.xref.Part1.53">13</a></li> 4987 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.23">3</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.48">10.9</a>, <a href="#rfc.xref.Part1.50">10.10</a></li> 4988 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.25">3.1</a></li> 4989 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.24">3.1</a></li> 4990 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.18">2.2.1</a>, <a href="#rfc.xref.Part1.35">4.4.6</a>, <a href="#rfc.xref.Part1.38">5</a>, <a href="#rfc.xref.Part1.46">7.2</a></li> 4991 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.56">A.6</a></li> 4992 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.45">7.1</a></li> 4993 <li><em>Section 4</em> <a href="#rfc.xref.Part1.43">6.4.1</a></li> 4994 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.28">3.1</a></li> 4995 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.52">11.4</a></li> 4996 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.44">6.4.1</a></li> 4997 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.53">11.4</a></li> 4998 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.42">6.4</a>, <a href="#rfc.xref.Part1.54">11.4</a></li> 4999 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1.15">1.3.2</a></li> 5000 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.30">3.2</a></li> 5001 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.19">2.3.1</a>, <a href="#rfc.xref.Part1.22">2.3.8</a></li> 5002 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.29">3.2</a></li> 5003 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.17">2</a>, <a href="#rfc.xref.Part1.31">3.3</a>, <a href="#rfc.xref.Part1.39">5.1</a>, <a href="#rfc.xref.Part1.51">10.17</a></li> 5004 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.27">3.1</a></li> 5005 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.49">10.9</a>, <a href="#rfc.xref.Part1.57">C</a></li> 5006 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.32">4.3.1</a>, <a href="#rfc.xref.Part1.47">10.3</a></li> 5007 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.33">4.3.2</a>, <a href="#rfc.xref.Part1.36">4.6.15</a></li> 5008 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.21">2.3.7</a></li> 5009 <li><em>Section 9</em> <a href="#rfc.xref.Part1.55">13</a></li> 5028 5010 </ul> 5029 5011 </li> -
draft-ietf-httpbis/experiment/p2-semantics.xml
r1629 r1630 314 314 <x:anchor-alias value="quoted-string"/> 315 315 <x:anchor-alias value="token"/> 316 <x:anchor-alias value="word"/> 316 317 <x:anchor-alias value="BWS"/> 317 318 <x:anchor-alias value="OWS"/> … … 327 328 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &field-components;> 328 329 <x:ref>token</x:ref> = <token, defined in &field-components;> 330 <x:ref>word</x:ref> = <word, defined in &field-components;> 329 331 </artwork></figure> 330 332 </section> … … 334 336 <x:anchor-alias value="comment"/> 335 337 <x:anchor-alias value="partial-URI"/> 338 <x:anchor-alias value="qvalue"/> 336 339 <x:anchor-alias value="URI-reference"/> 337 340 <t> … … 342 345 <x:ref>comment</x:ref> = <comment, defined in &field-components;> 343 346 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 347 <x:ref>qvalue</x:ref> = <qvalue, defined in &qvalue;> 344 348 <x:ref>URI-reference</x:ref> = <URI-reference, defined in &uri;> 345 349 </artwork></figure> … … 5526 5530 5527 5531 <x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT 5528 5529 5532 <x:ref>Max-Forwards</x:ref> = 1*DIGIT 5530 5533 … … 5532 5535 5533 5536 <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 3.2.1> 5534 5535 5537 <x:ref>Referer</x:ref> = absolute-URI / partial-URI 5536 5538 <x:ref>Retry-After</x:ref> = HTTP-date / delta-seconds … … 5539 5541 5540 5542 <x:ref>URI-reference</x:ref> = <URI-reference, defined in [Part1], Section 2.7> 5541 5542 5543 <x:ref>User-Agent</x:ref> = product *( RWS ( product / comment ) ) 5543 5544 5544 5545 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [Part1], Section 2.7> 5545 5546 5546 <x:ref>accept-ext</x:ref> = OWS ";" OWS token [ "=" word ] 5547 5547 <x:ref>accept-params</x:ref> = OWS ";" OWS "q=" qvalue *accept-ext 5548 5549 5548 <x:ref>asctime-date</x:ref> = day-name SP date3 SP time-of-day SP year 5550 5549 <x:ref>attribute</x:ref> = token 5551 5550 5552 5551 <x:ref>charset</x:ref> = token 5553 5554 5552 <x:ref>codings</x:ref> = content-coding / "identity" / "*" 5555 5556 5553 <x:ref>comment</x:ref> = <comment, defined in [Part1], Section 3.2.4> 5557 5554 <x:ref>content-coding</x:ref> = token 5558 5555 5559 5556 <x:ref>date1</x:ref> = day SP month SP year 5560 5561 5557 <x:ref>date2</x:ref> = day "-" month "-" 2DIGIT 5562 5563 5558 <x:ref>date3</x:ref> = month SP ( 2DIGIT / ( SP DIGIT ) ) 5564 5559 <x:ref>day</x:ref> = 2DIGIT … … 5580 5575 5581 5576 <x:ref>expect-name</x:ref> = token 5582 5583 5577 <x:ref>expect-param</x:ref> = expect-name [ BWS "=" BWS expect-value ] 5584 5585 5578 <x:ref>expect-value</x:ref> = token / quoted-string 5586 5579 <x:ref>expectation</x:ref> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ … … 5590 5583 5591 5584 <x:ref>language-range</x:ref> = <language-range, defined in [RFC4647], Section 2.1> 5592 5593 5585 <x:ref>language-tag</x:ref> = <Language-Tag, defined in [RFC5646], Section 2.1> 5594 5586 5595 5587 <x:ref>mailbox</x:ref> = <mailbox, defined in [RFC5322], Section 3.4> 5596 5597 5588 <x:ref>media-range</x:ref> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS 5598 5589 ";" OWS parameter ) … … 5614 5605 5615 5606 <x:ref>obs-date</x:ref> = rfc850-date / asctime-date 5616 5617 5607 <x:ref>obs-text</x:ref> = <obs-text, defined in [Part1], Section 3.2.4> 5618 5608 5619 5609 <x:ref>parameter</x:ref> = attribute "=" value 5620 5621 5610 <x:ref>partial-URI</x:ref> = <partial-URI, defined in [Part1], Section 2.7> 5622 5623 5611 <x:ref>product</x:ref> = token [ "/" product-version ] 5624 5612 <x:ref>product-version</x:ref> = token 5625 5613 5626 5614 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 3.2.4> 5615 <x:ref>qvalue</x:ref> = <qvalue, defined in [Part1], Section 4.3.1> 5627 5616 5628 5617 <x:ref>reason-phrase</x:ref> = *( HTAB / SP / VCHAR / obs-text ) 5629 5630 5618 <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT 5631 5632 5619 <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT 5633 5620 5634 5621 <x:ref>second</x:ref> = 2DIGIT 5635 5636 5622 <x:ref>status-code</x:ref> = 3DIGIT 5637 5638 5623 <x:ref>subtype</x:ref> = token 5639 5624 5640 5625 <x:ref>time-of-day</x:ref> = hour ":" minute ":" second 5641 5642 5626 <x:ref>token</x:ref> = <token, defined in [Part1], Section 3.2.4> 5643 5644 5627 <x:ref>type</x:ref> = token 5645 5628 5646 5629 <x:ref>value</x:ref> = word 5630 5631 <x:ref>word</x:ref> = <word, defined in [Part1], Section 3.2.4> 5647 5632 5648 5633 <x:ref>year</x:ref> = 4DIGIT … … 5650 5635 </figure> 5651 5636 <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> 5652 ; qvalue UNDEFINED5653 ; word UNDEFINED5654 5637 ; Accept defined but not used 5655 5638 ; Accept-Charset defined but not used -
draft-ietf-httpbis/experiment/p3-payload.html
r1627 r1630 407 407 <link rel="Copyright" href="#rfc.copyrightnotice"> 408 408 <link rel="Chapter" title="1 " href="#rfc.section.1"> 409 <link rel="Chapter" href="#rfc.section.2" title="2 References"> 410 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 411 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> 409 <link rel="Appendix" title="A Collected ABNF" href="#rfc.section.A"> 412 410 <link href="p2-semantics.html" rel="prev"> 413 411 <link href="p4-conditional.html" rel="next"> … … 487 485 <ul class="toc"> 488 486 <li>1. <a href="#rfc.section.1"></a></li> 489 <li>2. <a href="#rfc.references">References</a><ul>490 <li>2.1 <a href="#rfc.references.1">Normative References</a></li>491 <li>2.2 <a href="#rfc.references.2">Informative References</a></li>492 </ul>493 </li>494 487 <li><a href="#rfc.authors">Authors' Addresses</a></li> 495 <li>A. <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> 496 <li>B. <a href="#collected.abnf">Collected ABNF</a></li> 488 <li>A. <a href="#collected.abnf">Collected ABNF</a></li> 497 489 </ul> 498 490 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> 499 491 </h1> 500 <div id="rfc.figure.u.1"></div><pre class="inline">foo = bar 501 </pre><h1 id="rfc.references"><a id="rfc.section.2" href="#rfc.section.2">2.</a> References 502 </h1> 503 <h2 id="rfc.references.1"><a href="#rfc.section.2.1" id="rfc.section.2.1">2.1</a> Normative References 504 </h2> 505 <table> 506 <tr> 507 <td class="reference"><b id="Part1">[Part1]</b></td> 508 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), March 2012. 509 </td> 510 </tr> 511 <tr> 512 <td class="reference"><b id="Part2">[Part2]</b></td> 513 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), March 2012. 514 </td> 515 </tr> 516 <tr> 517 <td class="reference"><b id="Part4">[Part4]</b></td> 518 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), March 2012. 519 </td> 520 </tr> 521 <tr> 522 <td class="reference"><b id="Part5">[Part5]</b></td> 523 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), March 2012. 524 </td> 525 </tr> 526 <tr> 527 <td class="reference"><b id="Part6">[Part6]</b></td> 528 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net" title="Rackspace">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), March 2012. 529 </td> 530 </tr> 531 <tr> 532 <td class="reference"><b id="RFC1950">[RFC1950]</b></td> 533 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996. 534 </td> 535 </tr> 536 <tr> 537 <td class="reference"><b id="RFC1951">[RFC1951]</b></td> 538 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC 1951, May 1996. 539 </td> 540 </tr> 541 <tr> 542 <td class="reference"><b id="RFC1952">[RFC1952]</b></td> 543 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996. 544 </td> 545 </tr> 546 <tr> 547 <td class="reference"><b id="RFC4647">[RFC4647]</b></td> 548 <td class="top"><a href="mailto:addison@inter-locale.com" title="Yahoo! Inc.">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@macchiato.com" title="Google">M. Davis, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc4647">Matching of Language Tags</a>”, BCP 47, RFC 4647, September 2006. 549 </td> 550 </tr> 551 <tr> 552 <td class="reference"><b id="RFC5234">[RFC5234]</b></td> 553 <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD 68, RFC 5234, January 2008. 554 </td> 555 </tr> 556 <tr> 557 <td class="reference"><b id="RFC5646">[RFC5646]</b></td> 558 <td class="top"><a href="mailto:addison@inter-locale.com" title="Lab126">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@google.com" title="Google">M. Davis, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>”, BCP 47, RFC 5646, September 2009. 559 </td> 560 </tr> 561 </table> 562 <h2 id="rfc.references.2"><a href="#rfc.section.2.2" id="rfc.section.2.2">2.2</a> Informative References 563 </h2> 564 <table> 565 <tr> 566 <td class="reference"><b id="RFC1945">[RFC1945]</b></td> 567 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 568 </td> 569 </tr> 570 <tr> 571 <td class="reference"><b id="RFC2068">[RFC2068]</b></td> 572 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. 573 </td> 574 </tr> 575 <tr> 576 <td class="reference"><b id="RFC2277">[RFC2277]</b></td> 577 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998. 578 </td> 579 </tr> 580 <tr> 581 <td class="reference"><b id="RFC2295">[RFC2295]</b></td> 582 <td class="top"><a href="mailto:koen@win.tue.nl" title="Technische Universiteit Eindhoven">Holtman, K.</a> and <a href="mailto:mutz@hpl.hp.com" title="Hewlett-Packard Company">A. Mutz</a>, “<a href="http://tools.ietf.org/html/rfc2295">Transparent Content Negotiation in HTTP</a>”, RFC 2295, March 1998. 583 </td> 584 </tr> 585 <tr> 586 <td class="reference"><b id="RFC2388">[RFC2388]</b></td> 587 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC 2388, August 1998. 588 </td> 589 </tr> 590 <tr> 591 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 592 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 593 </td> 594 </tr> 595 <tr> 596 <td class="reference"><b id="RFC3629">[RFC3629]</b></td> 597 <td class="top"><a href="mailto:fyergeau@alis.com" title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>”, STD 63, RFC 3629, November 2003. 598 </td> 599 </tr> 600 <tr> 601 <td class="reference"><b id="RFC3864">[RFC3864]</b></td> 602 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 603 </td> 604 </tr> 605 <tr> 606 <td class="reference"><b id="RFC4288">[RFC4288]</b></td> 607 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 608 </td> 609 </tr> 610 <tr> 611 <td class="reference"><b id="RFC5226">[RFC5226]</b></td> 612 <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 5226, May 2008. 613 </td> 614 </tr> 615 <tr> 616 <td class="reference"><b id="RFC5322">[RFC5322]</b></td> 617 <td class="top">Resnick, P., “<a href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>”, RFC 5322, October 2008. 618 </td> 619 </tr> 620 </table> 621 <div class="avoidbreak"> 492 <div id="rfc.figure.u.1"></div><pre class="inline">this = <part does not have an ABNF anymore> 493 </pre><div class="avoidbreak"> 622 494 <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> 623 495 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span> … … 631 503 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 632 504 </div> 633 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 634 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 635 <div id="rfc.figure.u.2"></div> <pre class="inline">foo = bar 505 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 506 <div id="rfc.figure.u.2"></div> <pre class="inline">this = <part does not have an ABNF anymore> 636 507 </pre> <div id="rfc.figure.u.3"></div> 637 <p>ABNF diagnostics:</p><pre class="inline">; bar UNDEFINED 638 ; foo defined but not used 508 <p>ABNF diagnostics:</p><pre class="inline">; this defined but not used 639 509 </pre></body> 640 510 </html> -
draft-ietf-httpbis/experiment/p3-payload.xml
r1627 r1630 123 123 <section title=""> 124 124 <figure><artwork type="abnf2616"> 125 foo = bar 125 this = <part does not have an ABNF anymore> 126 126 </artwork></figure> 127 127 </section> … … 129 129 <back> 130 130 131 <references title="Normative References">132 133 <reference anchor="Part1">134 <front>135 <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>136 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">137 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>138 <address><email>fielding@gbiv.com</email></address>139 </author>140 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">141 <organization abbrev="W3C">World Wide Web Consortium</organization>142 <address><email>ylafon@w3.org</email></address>143 </author>144 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">145 <organization abbrev="greenbytes">greenbytes GmbH</organization>146 <address><email>julian.reschke@greenbytes.de</email></address>147 </author>148 <date month="&ID-MONTH;" year="&ID-YEAR;"/>149 </front>150 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>151 <x:source href="p1-messaging.xml" basename="p1-messaging"/>152 </reference>153 154 <reference anchor="Part2">155 <front>156 <title abbrev="HTTP/1.1">HTTP/1.1, part 2: Message Semantics</title>157 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">158 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>159 <address><email>fielding@gbiv.com</email></address>160 </author>161 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">162 <organization abbrev="W3C">World Wide Web Consortium</organization>163 <address><email>ylafon@w3.org</email></address>164 </author>165 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">166 <organization abbrev="greenbytes">greenbytes GmbH</organization>167 <address><email>julian.reschke@greenbytes.de</email></address>168 </author>169 <date month="&ID-MONTH;" year="&ID-YEAR;"/>170 </front>171 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>172 <x:source href="p2-semantics.xml" basename="p2-semantics"/>173 </reference>174 175 <reference anchor="Part4">176 <front>177 <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>178 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">179 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>180 <address><email>fielding@gbiv.com</email></address>181 </author>182 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">183 <organization abbrev="W3C">World Wide Web Consortium</organization>184 <address><email>ylafon@w3.org</email></address>185 </author>186 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">187 <organization abbrev="greenbytes">greenbytes GmbH</organization>188 <address><email>julian.reschke@greenbytes.de</email></address>189 </author>190 <date month="&ID-MONTH;" year="&ID-YEAR;"/>191 </front>192 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/>193 <x:source href="p4-conditional.xml" basename="p4-conditional"/>194 </reference>195 196 <reference anchor="Part5">197 <front>198 <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>199 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">200 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>201 <address><email>fielding@gbiv.com</email></address>202 </author>203 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">204 <organization abbrev="W3C">World Wide Web Consortium</organization>205 <address><email>ylafon@w3.org</email></address>206 </author>207 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">208 <organization abbrev="greenbytes">greenbytes GmbH</organization>209 <address><email>julian.reschke@greenbytes.de</email></address>210 </author>211 <date month="&ID-MONTH;" year="&ID-YEAR;"/>212 </front>213 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;"/>214 <x:source href="p5-range.xml" basename="p5-range"/>215 </reference>216 217 <reference anchor="Part6">218 <front>219 <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>220 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">221 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>222 <address><email>fielding@gbiv.com</email></address>223 </author>224 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">225 <organization abbrev="W3C">World Wide Web Consortium</organization>226 <address><email>ylafon@w3.org</email></address>227 </author>228 <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">229 <organization>Rackspace</organization>230 <address><email>mnot@mnot.net</email></address>231 </author>232 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">233 <organization abbrev="greenbytes">greenbytes GmbH</organization>234 <address><email>julian.reschke@greenbytes.de</email></address>235 </author>236 <date month="&ID-MONTH;" year="&ID-YEAR;"/>237 </front>238 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>239 <x:source href="p6-cache.xml" basename="p6-cache"/>240 </reference>241 242 <reference anchor="RFC1950">243 <front>244 <title>ZLIB Compressed Data Format Specification version 3.3</title>245 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">246 <organization>Aladdin Enterprises</organization>247 <address><email>ghost@aladdin.com</email></address>248 </author>249 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"/>250 <date month="May" year="1996"/>251 </front>252 <seriesInfo name="RFC" value="1950"/>253 <!--<annotation>254 RFC 1950 is an Informational RFC, thus it might be less stable than255 this specification. On the other hand, this downward reference was256 present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,257 therefore it is unlikely to cause problems in practice. See also258 <xref target="BCP97"/>.259 </annotation>-->260 </reference>261 262 <reference anchor="RFC1951">263 <front>264 <title>DEFLATE Compressed Data Format Specification version 1.3</title>265 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">266 <organization>Aladdin Enterprises</organization>267 <address><email>ghost@aladdin.com</email></address>268 </author>269 <date month="May" year="1996"/>270 </front>271 <seriesInfo name="RFC" value="1951"/>272 <!--<annotation>273 RFC 1951 is an Informational RFC, thus it might be less stable than274 this specification. On the other hand, this downward reference was275 present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,276 therefore it is unlikely to cause problems in practice. See also277 <xref target="BCP97"/>.278 </annotation>-->279 </reference>280 281 <reference anchor="RFC1952">282 <front>283 <title>GZIP file format specification version 4.3</title>284 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">285 <organization>Aladdin Enterprises</organization>286 <address><email>ghost@aladdin.com</email></address>287 </author>288 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">289 <address><email>gzip@prep.ai.mit.edu</email></address>290 </author>291 <author initials="M." surname="Adler" fullname="Mark Adler">292 <address><email>madler@alumni.caltech.edu</email></address>293 </author>294 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">295 <address><email>ghost@aladdin.com</email></address>296 </author>297 <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">298 <address><email>randeg@alumni.rpi.edu</email></address>299 </author>300 <date month="May" year="1996"/>301 </front>302 <seriesInfo name="RFC" value="1952"/>303 <!--<annotation>304 RFC 1952 is an Informational RFC, thus it might be less stable than305 this specification. On the other hand, this downward reference was306 present since the publication of <xref target="RFC2068" x:fmt="none">RFC 2068</xref> in 1997,307 therefore it is unlikely to cause problems in practice. See also308 <xref target="BCP97"/>.309 </annotation>-->310 </reference>311 312 <reference anchor='RFC4647'>313 <front>314 <title>Matching of Language Tags</title>315 <author initials='A.' surname='Phillips' fullname='Addison Phillips' role="editor">316 <organization>Yahoo! Inc.</organization>317 <address><email>addison@inter-locale.com</email></address>318 </author>319 <author initials='M.' surname='Davis' fullname='Mark Davis' role="editor">320 <organization>Google</organization>321 <address><email>mark.davis@macchiato.com</email></address>322 </author>323 <date year='2006' month='September' />324 </front>325 <seriesInfo name='BCP' value='47' />326 <seriesInfo name='RFC' value='4647' />327 </reference>328 329 <reference anchor="RFC5234">330 <front>331 <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>332 <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">333 <organization>Brandenburg InternetWorking</organization>334 <address>335 <email>dcrocker@bbiw.net</email>336 </address>337 </author>338 <author initials="P." surname="Overell" fullname="Paul Overell">339 <organization>THUS plc.</organization>340 <address>341 <email>paul.overell@thus.net</email>342 </address>343 </author>344 <date month="January" year="2008"/>345 </front>346 <seriesInfo name="STD" value="68"/>347 <seriesInfo name="RFC" value="5234"/>348 </reference>349 350 <reference anchor='RFC5646'>351 <front>352 <title>Tags for Identifying Languages</title>353 <author initials='A.' surname='Phillips' fullname='Addison Phillips' role='editor'>354 <organization>Lab126</organization>355 <address><email>addison@inter-locale.com</email></address>356 </author>357 <author initials='M.' surname='Davis' fullname='Mark Davis' role='editor'>358 <organization>Google</organization>359 <address><email>mark.davis@google.com</email></address>360 </author>361 <date month='September' year='2009' />362 </front>363 <seriesInfo name='BCP' value='47' />364 <seriesInfo name='RFC' value='5646' />365 </reference>366 367 </references>368 369 <references title="Informative References">370 371 <reference anchor="RFC1945">372 <front>373 <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>374 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">375 <organization>MIT, Laboratory for Computer Science</organization>376 <address><email>timbl@w3.org</email></address>377 </author>378 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">379 <organization>University of California, Irvine, Department of Information and Computer Science</organization>380 <address><email>fielding@ics.uci.edu</email></address>381 </author>382 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">383 <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>384 <address><email>frystyk@w3.org</email></address>385 </author>386 <date month="May" year="1996"/>387 </front>388 <seriesInfo name="RFC" value="1945"/>389 </reference>390 391 <reference anchor="RFC2068">392 <front>393 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>394 <author initials="R." surname="Fielding" fullname="Roy T. Fielding">395 <organization>University of California, Irvine, Department of Information and Computer Science</organization>396 <address><email>fielding@ics.uci.edu</email></address>397 </author>398 <author initials="J." surname="Gettys" fullname="Jim Gettys">399 <organization>MIT Laboratory for Computer Science</organization>400 <address><email>jg@w3.org</email></address>401 </author>402 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">403 <organization>Digital Equipment Corporation, Western Research Laboratory</organization>404 <address><email>mogul@wrl.dec.com</email></address>405 </author>406 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">407 <organization>MIT Laboratory for Computer Science</organization>408 <address><email>frystyk@w3.org</email></address>409 </author>410 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">411 <organization>MIT Laboratory for Computer Science</organization>412 <address><email>timbl@w3.org</email></address>413 </author>414 <date month="January" year="1997"/>415 </front>416 <seriesInfo name="RFC" value="2068"/>417 </reference>418 419 <reference anchor="RFC2277">420 <front>421 <title abbrev="Charset Policy">IETF Policy on Character Sets and Languages</title>422 <author initials="H.T." surname="Alvestrand" fullname="Harald Tveit Alvestrand">423 <organization>UNINETT</organization>424 <address><email>Harald.T.Alvestrand@uninett.no</email></address>425 </author>426 <date month="January" year="1998"/>427 </front>428 <seriesInfo name="BCP" value="18"/>429 <seriesInfo name="RFC" value="2277"/>430 </reference>431 432 <reference anchor='RFC2295'>433 <front>434 <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title>435 <author initials='K.' surname='Holtman' fullname='Koen Holtman'>436 <organization>Technische Universiteit Eindhoven</organization>437 <address>438 <email>koen@win.tue.nl</email>439 </address>440 </author>441 <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'>442 <organization>Hewlett-Packard Company</organization>443 <address>444 <email>mutz@hpl.hp.com</email>445 </address>446 </author>447 <date year='1998' month='March'/>448 </front>449 <seriesInfo name='RFC' value='2295'/>450 </reference>451 452 <reference anchor="RFC2388">453 <front>454 <title abbrev="multipart/form-data">Returning Values from Forms: multipart/form-data</title>455 <author initials="L." surname="Masinter" fullname="Larry Masinter">456 <organization>Xerox Palo Alto Research Center</organization>457 <address><email>masinter@parc.xerox.com</email></address>458 </author>459 <date year="1998" month="August"/>460 </front>461 <seriesInfo name="RFC" value="2388"/>462 </reference>463 464 <reference anchor="RFC2616">465 <front>466 <title>Hypertext Transfer Protocol -- HTTP/1.1</title>467 <author initials="R." surname="Fielding" fullname="R. Fielding">468 <organization>University of California, Irvine</organization>469 <address><email>fielding@ics.uci.edu</email></address>470 </author>471 <author initials="J." surname="Gettys" fullname="J. Gettys">472 <organization>W3C</organization>473 <address><email>jg@w3.org</email></address>474 </author>475 <author initials="J." surname="Mogul" fullname="J. Mogul">476 <organization>Compaq Computer Corporation</organization>477 <address><email>mogul@wrl.dec.com</email></address>478 </author>479 <author initials="H." surname="Frystyk" fullname="H. Frystyk">480 <organization>MIT Laboratory for Computer Science</organization>481 <address><email>frystyk@w3.org</email></address>482 </author>483 <author initials="L." surname="Masinter" fullname="L. Masinter">484 <organization>Xerox Corporation</organization>485 <address><email>masinter@parc.xerox.com</email></address>486 </author>487 <author initials="P." surname="Leach" fullname="P. Leach">488 <organization>Microsoft Corporation</organization>489 <address><email>paulle@microsoft.com</email></address>490 </author>491 <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">492 <organization>W3C</organization>493 <address><email>timbl@w3.org</email></address>494 </author>495 <date month="June" year="1999"/>496 </front>497 <seriesInfo name="RFC" value="2616"/>498 </reference>499 500 <reference anchor="RFC3629">501 <front>502 <title>UTF-8, a transformation format of ISO 10646</title>503 <author initials="F." surname="Yergeau" fullname="F. Yergeau">504 <organization>Alis Technologies</organization>505 <address><email>fyergeau@alis.com</email></address>506 </author>507 <date month="November" year="2003"/>508 </front>509 <seriesInfo name="STD" value="63"/>510 <seriesInfo name="RFC" value="3629"/>511 </reference>512 513 <reference anchor='RFC3864'>514 <front>515 <title>Registration Procedures for Message Header Fields</title>516 <author initials='G.' surname='Klyne' fullname='G. Klyne'>517 <organization>Nine by Nine</organization>518 <address><email>GK-IETF@ninebynine.org</email></address>519 </author>520 <author initials='M.' surname='Nottingham' fullname='M. Nottingham'>521 <organization>BEA Systems</organization>522 <address><email>mnot@pobox.com</email></address>523 </author>524 <author initials='J.' surname='Mogul' fullname='J. Mogul'>525 <organization>HP Labs</organization>526 <address><email>JeffMogul@acm.org</email></address>527 </author>528 <date year='2004' month='September' />529 </front>530 <seriesInfo name='BCP' value='90' />531 <seriesInfo name='RFC' value='3864' />532 </reference>533 534 <reference anchor="RFC4288">535 <front>536 <title>Media Type Specifications and Registration Procedures</title>537 <author initials="N." surname="Freed" fullname="N. Freed">538 <organization>Sun Microsystems</organization>539 <address>540 <email>ned.freed@mrochek.com</email>541 </address>542 </author>543 <author initials="J." surname="Klensin" fullname="J. Klensin">544 <address>545 <email>klensin+ietf@jck.com</email>546 </address>547 </author>548 <date year="2005" month="December"/>549 </front>550 <seriesInfo name="BCP" value="13"/>551 <seriesInfo name="RFC" value="4288"/>552 </reference>553 554 <reference anchor='RFC5226'>555 <front>556 <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>557 <author initials='T.' surname='Narten' fullname='T. Narten'>558 <organization>IBM</organization>559 <address><email>narten@us.ibm.com</email></address>560 </author>561 <author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>562 <organization>Google</organization>563 <address><email>Harald@Alvestrand.no</email></address>564 </author>565 <date year='2008' month='May' />566 </front>567 <seriesInfo name='BCP' value='26' />568 <seriesInfo name='RFC' value='5226' />569 </reference>570 571 <reference anchor="RFC5322">572 <front>573 <title>Internet Message Format</title>574 <author initials="P." surname="Resnick" fullname="P. Resnick">575 <organization>Qualcomm Incorporated</organization>576 </author>577 <date year="2008" month="October"/>578 </front>579 <seriesInfo name="RFC" value="5322"/>580 </reference>581 582 <!--<reference anchor='BCP97'>583 <front>584 <title>Handling Normative References to Standards-Track Documents</title>585 <author initials='J.' surname='Klensin' fullname='J. Klensin'>586 <address>587 <email>klensin+ietf@jck.com</email>588 </address>589 </author>590 <author initials='S.' surname='Hartman' fullname='S. Hartman'>591 <organization>MIT</organization>592 <address>593 <email>hartmans-ietf@mit.edu</email>594 </address>595 </author>596 <date year='2007' month='June' />597 </front>598 <seriesInfo name='BCP' value='97' />599 <seriesInfo name='RFC' value='4897' />600 </reference>-->601 602 603 </references>604 605 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">606 </section>607 608 131 <?BEGININC p3-payload.abnf-appendix ?> 609 132 <section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf"> 610 133 <figure> 611 134 <artwork type="abnf" name="p3-payload.parsed-abnf"> 612 foo = bar 135 this = <part does not have an ABNF anymore> 613 136 </artwork> 614 137 </figure> 615 138 <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"> 616 ; bar UNDEFINED 617 ; foo defined but not used 139 ; this defined but not used 618 140 </artwork></figure></section> 619 141 <?ENDINC p3-payload.abnf-appendix ?> -
draft-ietf-httpbis/experiment/p4-conditional.html
r1627 r1630 896 896 </div> 897 897 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p 3-payload.html#content.negotiation" title="ERROR: Anchor 'content.negotiation' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.negotiation' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="ERROR: Anchor 'header.accept-encoding' not found in p3-payload.xml.">Appendix ERROR: Anchor 'header.accept-encoding' in Part3 not found in source file 'p3-payload.xml'.</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 10.13</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>): 899 899 </p> 900 900 <div id="rfc.figure.u.6"></div> … … 1123 1123 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1124 1124 </p> 1125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 1 1.2</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 2001125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200 1126 1126 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires, 1127 1127 or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. … … 1245 1245 <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References 1246 1246 </h2> 1247 <table> 1247 <table> 1248 1248 <tr> 1249 1249 <td class="reference"><b id="Part1">[Part1]</b></td> … … 1254 1254 <td class="reference"><b id="Part2">[Part2]</b></td> 1255 1255 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), March 2012. 1256 </td>1257 </tr>1258 <tr>1259 <td class="reference"><b id="Part3">[Part3]</b></td>1260 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-latest (work in progress), March 2012.1261 1256 </td> 1262 1257 </tr> … … 1428 1423 </ul> 1429 1424 </li> 1430 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3"> 4.1</a>, <a href="#Part2"><b>8.1</b></a><ul>1425 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">4.1</a>, <a href="#Part2"><b>8.1</b></a><ul> 1431 1426 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.2">1.2</a></li> 1432 <li><em>Section 11.2</em> <a href="#rfc.xref.Part2.3">4.1</a></li> 1433 </ul> 1434 </li> 1435 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2.3.3</a>, <a href="#rfc.xref.Part3.2">2.3.3</a>, <a href="#Part3"><b>8.1</b></a><ul> 1436 <li><em>Appendix </em> <a href="#rfc.xref.Part3.1">2.3.3</a></li> 1437 <li><em>Appendix </em> <a href="#rfc.xref.Part3.2">2.3.3</a></li> 1427 <li><em>Section 9</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1428 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.5">4.1</a></li> 1429 <li><em>Section 10.13</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li> 1438 1430 </ul> 1439 1431 </li> -
draft-ietf-httpbis/experiment/p4-conditional.xml
r1625 r1630 24 24 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY header-accept-encoding "<xref target='Part 3' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">26 <!ENTITY header-accept-encoding "<xref target='Part2' x:rel='#header.accept-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 27 <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 30 30 <!ENTITY http-date "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY transfer-codings "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 <!ENTITY content-negotiation "<xref target='Part 3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">32 <!ENTITY content-negotiation "<xref target='Part2' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 33 ]> 34 34 <?rfc toc="yes" ?> … … 1191 1191 </reference> 1192 1192 1193 <reference anchor="Part3">1194 <front>1195 <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>1196 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">1197 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>1198 <address><email>fielding@gbiv.com</email></address>1199 </author>1200 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">1201 <organization abbrev="W3C">World Wide Web Consortium</organization>1202 <address><email>ylafon@w3.org</email></address>1203 </author>1204 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">1205 <organization abbrev="greenbytes">greenbytes GmbH</organization>1206 <address><email>julian.reschke@greenbytes.de</email></address>1207 </author>1208 <date month="&ID-MONTH;" year="&ID-YEAR;"/>1209 </front>1210 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/>1211 <x:source href="p3-payload.xml" basename="p3-payload"/>1212 </reference>1213 1214 1193 <reference anchor="Part5"> 1215 1194 <front> -
draft-ietf-httpbis/experiment/p6-cache.html
r1627 r1630 987 987 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 988 988 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 989 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 1 1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.989 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 990 990 </li> 991 991 </ul> … … 2185 2185 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2.3.1.1</a></li> 2186 2186 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li> 2187 <li><em>Section 1 1.2</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li>2187 <li><em>Section 10.2</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li> 2188 2188 </ul> 2189 2189 </li>
Note: See TracChangeset
for help on using the changeset viewer.