Changeset 1630


Ignore:
Timestamp:
28/03/12 16:18:53 (9 years ago)
Author:
julian.reschke@…
Message:
 
Location:
draft-ietf-httpbis/experiment
Files:
9 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/experiment/httpbis.abnf

    r1627 r1630  
    135135field-value = *( field-content / obs-fold )
    136136first-byte-pos = 1*DIGIT
    137 ; bar UNDEFINED
    138 foo = bar
    139137header-field = field-name ":" OWS field-value BWS
    140138hour = 2DIGIT
    … …  
    220218te-ext = OWS ";" OWS token [ "=" word ]
    221219te-params = OWS ";" OWS "q=" qvalue *te-ext
     220this = <part does not have an ABNF anymore>
    222221time-of-day = hour ":" minute ":" second
    223222token = 1*tchar
    … …  
    287286; Warning defined but not used
    288287; chunked-body defined but not used
    289 ; foo defined but not used
    290288; http-URI defined but not used
    291289; https-URI defined but not used
    292290; special defined but not used
     291; this defined but not used

  • draft-ietf-httpbis/experiment/p1-messaging.html

    r1629 r1630  
    757757      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    758758         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&nbsp;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&nbsp;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).
    760760      </p>
    761761      <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
    … …  
    910910         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    911911         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.
    913913      </p>
    914914      <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
    … …  
    10781078      </p>
    10791079      <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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;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&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;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.
    10811081      </p>
    10821082      <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
    … …  
    11741174      </div>
    11751175      <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.
    11771177      </p>
    11781178      <div id="rfc.iref.r.6"></div>
    … …  
    11891189      <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
    11901190         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>).
    11921192      </p>
    11931193      <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.
    … …  
    11991199      <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>
    12001200</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 considerations
     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="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
    12021202            for new status codes.
    12031203         </p>
    … …  
    12231223                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.2</a>
    12241224</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.
    12261226      </p>
    12271227      <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
    … …  
    12311231         them.
    12321232      </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&nbsp;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&nbsp;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.
    12341234      </p>
    12351235      <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"
    … …  
    14181418      <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&nbsp;3.2</a>, before determining the message body length.
    14191419      </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.
    14211421      </p>
    14221422      <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
    … …  
    17251725      </p>
    17261726      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<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&nbsp;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 weight
     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&nbsp;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
    17281728         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
    17291729         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.
    … …  
    18261826      </p>
    18271827      <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,
    18291829         </p>
    18301830      </div>
    18311831      <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
    18321832</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,
    18341834            the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    18351835         </p>
    … …  
    19921992         messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    19931993         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.
    19951995      </p>
    19961996      <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.
    … …  
    21372137      <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.
    21382138      </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 to
     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="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
    21402140         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.
    21412141      </p>
    … …  
    21672167      <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
    21682168      <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 understanding
     2169         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
    21702170         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.
    21712171      </p>
    … …  
    21802180      </p>
    21812181      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<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 willing
     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="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
    21832183         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21842184         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21872187      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21882188      <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="ERROR: 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="ERROR: 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.
    21922192         </li>
    21932193      </ul>
    … …  
    22332233         <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
    22342234            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>).
    22362236         </li>
    22372237      </ul>
    … …  
    22702270      </p>
    22712271      <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>).
    22732273      </p>
    22742274      <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
    … …  
    25342534         <li>Pointer to specification text</li>
    25352535      </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&nbsp;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&nbsp;4.2</a>.
    25372537      </p>
    25382538      <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.
    … …  
    26942694         that most implementations will choose substantially higher limits.
    26952695      </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>).
    26972697      </p>
    26982698      <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.
    … …  
    37463746                  <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
    37473747                  <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    3749                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
    3750                         <li><em>Appendix </em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
    3752                         <li><em>Appendix </em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
    3754                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
    3755                         <li><em>Appendix </em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
    3757                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
    3758                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
    3759                         <li><em>Appendix </em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.4.3</a></li>
    3762                         <li><em>Appendix </em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.5</a></li>
    3764                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">8.6</a></li>
     3748                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
     3749                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
     3751                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
     3752                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
     3753                        <li><em>Section 4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.4.3</a></li>
     3756                        <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
     3757                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.5</a></li>
     3758                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">8.6</a></li>
     3759                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
     3762                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
     3763                        <li><em>Section 10.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
    37653765                     </ul>
    37663766                  </li>

  • draft-ietf-httpbis/experiment/p2-semantics.html

    r1629 r1630  
    895895  <a href="#core.rules" class="smpl">quoted-string</a> = &lt;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>&gt;
    896896  <a href="#core.rules" class="smpl">token</a>         = &lt;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>&gt;
     897  <a href="#core.rules" class="smpl">word</a>          = &lt;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>&gt;
    897898</pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    898899      <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>  = &lt;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>&gt;
    900   <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;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>&gt;
    901   <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;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>&gt;
    902   <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;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>&gt;
     900      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>  = &lt;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>&gt;
     901  <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;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>&gt;
     902  <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;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>&gt;
     903  <a href="#abnf.dependencies" class="smpl">qvalue</a>        = &lt;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>&gt;
     904  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;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>&gt;
    903905</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<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.15"><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.
    905907      </p>
    906908      <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>
    … …  
    953955         to a single application, so that this is clear.
    954956      </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.16"><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
     957      <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
    956958         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    957959         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    973975         to HTTP might use the OPTIONS body to make more detailed queries on the server.
    974976      </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.17"><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.
    976978         Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op"
    977979         type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be
    … …  
    11361138      </p>
    11371139      <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 the
     1140         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
    11391141         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    11401142         infinite loop.
    11411143      </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.
    11431145      </p>
    11441146      <div id="rfc.iref.c.2"></div>
    … …  
    11481150         its behavior to blind forwarding of packets until the connection is closed.
    11491151      </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.20"><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.
    11511153         For example,
    11521154      </p>
    … …  
    11841186      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1>
    11851187      <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.21"><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.
    11871189      </p>
    11881190      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2>
    … …  
    11921194         with "X-" if they are to be registered (either immediately or in the future).
    11931195      </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.22"><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
     1196      <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
    11951197         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>.
    11961198      </p>
    11971199      <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
    11981200         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.23"><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>).
    12001202      </p>
    12011203      <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
    … …  
    12151217      <ul>
    12161218         <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.24"><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>).
    12181220            </p>
    12191221            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible
    … …  
    12311233         </li>
    12321234         <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.25"><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>).
    12341236            </p>
    12351237         </li>
    … …  
    12421244         </li>
    12431245         <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.26"><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>).
    12451247            </p>
    12461248         </li>
    … …  
    12931295               <tr>
    12941296                  <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.27"><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>
    12961298               </tr>
    12971299               <tr>
    … …  
    13331335               <tr>
    13341336                  <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>
    13361338               </tr>
    13371339               <tr>
    … …  
    13441346      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    13451347      <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>).
    13471349      </p>
    13481350      <div id="rfc.table.u.2">
    … …  
    16911693      <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
    16921694         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.30"><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.
    16941696      </p>
    16951697      <div id="rfc.iref.25"></div>
    16961698      <div id="rfc.iref.s.4"></div>
    16971699      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<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.31"><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
     1700      <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
    16991701         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    17001702      </p>
    … …  
    17491751      <div id="rfc.iref.s.8"></div>
    17501752      <h3 id="rfc.section.4.4.4"><a href="#rfc.section.4.4.4">4.4.4</a>&nbsp;<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.32"><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>).
    17521754      </p>
    17531755      <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
    … …  
    17841786         another input action.
    17851787      </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.33"><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>.
    17871789      </p>
    17881790      <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    20442046      <div id="rfc.iref.s.32"></div>
    20452047      <h3 id="rfc.section.4.6.15"><a href="#rfc.section.4.6.15">4.6.15</a>&nbsp;<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.34"><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.
    20472049      </p>
    20482050      <div id="rfc.figure.u.8"></div>
    … …  
    21052107      <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
    21062108         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.35"><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.
    21082110      </p>
    21092111      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    … …  
    21122114         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&nbsp;7</a>.
    21132115      </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.36"><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
     2116      <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
    21152117         to ensure safe and proper transfer of the message.
    21162118      </p>
    … …  
    21182120      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    21192121      <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.37"><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
     2122      <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
    21212123         rules are used (with the first applicable one being selected):
    21222124      </p>
    … …  
    22692271      </p>
    22702272      <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>.
    22722274         </li>
    22732275      </ul>
    … …  
    22752277      </p>
    22762278      <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>.
    22782280         </li>
    22792281      </ul>
    … …  
    22812283      </p>
    22822284      <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.40"><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>.
    22842286         </li>
    22852287      </ul>
    … …  
    22932295         <li>Pointer to specification text</li>
    22942296      </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.41"><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>).
    22962298      </p>
    22972299      <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.
    … …  
    23112313      <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>
    23122314  <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>          = word
     2315  <a href="#rule.parameter" class="smpl">value</a>          = <a href="#core.rules" class="smpl">word</a>
    23142316</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,
    23152317         depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing
    … …  
    23932395               <tr>
    23942396                  <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.43"><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>
    23962398               </tr>
    23972399               <tr>
    … …  
    24032405      </div>
    24042406      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<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.44"><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
     2407      <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
    24062408         safe and proper transfer of the message.
    24072409      </p>
    … …  
    26572659      </p>
    26582660      <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.45"><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.
    26602662         </li>
    26612663      </ul>
    … …  
    27692771      <h2 id="rfc.section.10.9"><a href="#rfc.section.10.9">10.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    27702772      <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&nbsp;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.46"><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
     2773      <p id="rfc.section.10.9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;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
    27722774         identifying the application.
    27732775      </p>
    … …  
    27752777</pre><p id="rfc.section.10.9.p.4">Example:</p>
    27762778      <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.47"><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>).
    27782780      </p>
    27792781      <div class="note" id="rfc.section.10.9.p.7">
    … …  
    27912793         user agent limitations.
    27922794      </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&nbsp;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 significance
     2795      <p id="rfc.section.10.10.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section&nbsp;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
    27942796         for identifying the application.
    27952797      </p>
    … …  
    28182820                   / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> )
    28192821                   ) *( <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> ]
    28222824</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
    28232825         all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range.
    … …  
    29152917      </p>
    29162918      <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> ] )
    29182920</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&nbsp;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
    29192921         example is
    … …  
    29352937         no encoding is preferred.
    29362938      </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> ] )
    29382940  <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*"
    29392941</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.
    … …  
    29792981      </p>
    29802982      <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> ] )
    29822984  <a href="#header.accept-language" class="smpl">language-range</a>  =
    29832985            &lt;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>&gt;
    … …  
    30703072      </p>
    30713073      <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 MIME
     3074</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
    30733075         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.
    30743076      </p>
    … …  
    35903592                  <td class="left">compress</td>
    35913593                  <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.50"><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>
    35933595                  </td>
    35943596               </tr>
    … …  
    35973599                  <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>)
    35983600                  </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.51"><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>
    36003602                  </td>
    36013603               </tr>
    … …  
    36033605                  <td class="left">gzip</td>
    36043606                  <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.52"><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>
    36063608                  </td>
    36073609               </tr>
    … …  
    36983700      </p>
    36993701      <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<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.53"><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>.
    37013703      </p>
    37023704      <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References
    … …  
    39553957      </p>
    39563958      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<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.54"><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.
    39583960      </p>
    39593961      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    … …  
    40104012      </p>
    40114013      <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.55"><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&nbsp;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&nbsp;10.9</a>)
    40134015      </p>
    40144016      <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;6.3</a>)
    … …  
    40684070
    40694071<a href="#mime-version" class="smpl">MIME-Version</a> = 1*DIGIT "." 1*DIGIT
    4070 
    40714072<a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*DIGIT
    40724073
    … …  
    40744075
    40754076<a href="#core.rules" class="smpl">RWS</a> = &lt;RWS, defined in [Part1], Section 3.2.1&gt;
    4076 
    40774077<a href="#header.referer" class="smpl">Referer</a> = absolute-URI / partial-URI
    40784078<a href="#header.retry-after" class="smpl">Retry-After</a> = HTTP-date / delta-seconds
    … …  
    40814081
    40824082<a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in [Part1], Section 2.7&gt;
    4083 
    40844083<a href="#header.user-agent" class="smpl">User-Agent</a> = product *( RWS ( product / comment ) )
    40854084
    40864085<a href="#abnf.dependencies" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [Part1], Section 2.7&gt;
    4087 
    40884086<a href="#header.accept" class="smpl">accept-ext</a> = OWS ";" OWS token [ "=" word ]
    40894087<a href="#header.accept" class="smpl">accept-params</a> = OWS ";" OWS "q=" qvalue *accept-ext
    4090 
    40914088<a href="#obsolete.date.formats" class="smpl">asctime-date</a> = day-name SP date3 SP time-of-day SP year
    40924089<a href="#rule.parameter" class="smpl">attribute</a> = token
    40934090
    40944091<a href="#rule.charset" class="smpl">charset</a> = token
    4095 
    40964092<a href="#header.accept-encoding" class="smpl">codings</a> = content-coding / "identity" / "*"
    4097 
    40984093<a href="#abnf.dependencies" class="smpl">comment</a> = &lt;comment, defined in [Part1], Section 3.2.4&gt;
    40994094<a href="#content.codings" class="smpl">content-coding</a> = token
    41004095
    41014096<a href="#obsolete.date.formats" class="smpl">date1</a> = day SP month SP year
    4102 
    41034097<a href="#obsolete.date.formats" class="smpl">date2</a> = day "-" month "-" 2DIGIT
    4104 
    41054098<a href="#obsolete.date.formats" class="smpl">date3</a> = month SP ( 2DIGIT / ( SP DIGIT ) )
    41064099<a href="#preferred.date.format" class="smpl">day</a> = 2DIGIT
    … …  
    41224115
    41234116<a href="#header.expect" class="smpl">expect-name</a> = token
    4124 
    41254117<a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ]
    4126 
    41274118<a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string
    41284119<a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
    … …  
    41324123
    41334124<a href="#header.accept-language" class="smpl">language-range</a> = &lt;language-range, defined in [RFC4647], Section 2.1&gt;
    4134 
    41354125<a href="#language.tags" class="smpl">language-tag</a> = &lt;Language-Tag, defined in [RFC5646], Section 2.1&gt;
    41364126
    41374127<a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in [RFC5322], Section 3.4&gt;
    4138 
    41394128<a href="#header.accept" class="smpl">media-range</a> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
    41404129 ";" OWS parameter )
    … …  
    41564145
    41574146<a href="#obsolete.date.formats" class="smpl">obs-date</a> = rfc850-date / asctime-date
    4158 
    41594147<a href="#core.rules" class="smpl">obs-text</a> = &lt;obs-text, defined in [Part1], Section 3.2.4&gt;
    41604148
    41614149<a href="#rule.parameter" class="smpl">parameter</a> = attribute "=" value
    4162 
    41634150<a href="#abnf.dependencies" class="smpl">partial-URI</a> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    4164 
    41654151<a href="#product.tokens" class="smpl">product</a> = token [ "/" product-version ]
    41664152<a href="#product.tokens" class="smpl">product-version</a> = token
    41674153
    41684154<a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in [Part1], Section 3.2.4&gt;
     4155<a href="#abnf.dependencies" class="smpl">qvalue</a> = &lt;qvalue, defined in [Part1], Section 4.3.1&gt;
    41694156
    41704157<a href="#status.code.and.reason.phrase" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text )
    4171 
    41724158<a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT
    4173 
    41744159<a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT
    41754160
    41764161<a href="#preferred.date.format" class="smpl">second</a> = 2DIGIT
    4177 
    41784162<a href="#status.code.and.reason.phrase" class="smpl">status-code</a> = 3DIGIT
    4179 
    41804163<a href="#media.types" class="smpl">subtype</a> = token
    41814164
    41824165<a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second
    4183 
    41844166<a href="#core.rules" class="smpl">token</a> = &lt;token, defined in [Part1], Section 3.2.4&gt;
    4185 
    41864167<a href="#media.types" class="smpl">type</a> = token
    41874168
    41884169<a href="#rule.parameter" class="smpl">value</a> = word
    41894170
     4171<a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 3.2.4&gt;
     4172
    41904173<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
    41914174</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
    41954176; Accept-Charset defined but not used
    41964177; Accept-Encoding defined but not used
    … …  
    49974978            </li>
    49984979            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    4999                   <li><em>Part1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    50004981                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.3</a></li>
    50014982                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    5002                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">4.4.4</a></li>
    5003                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">4.7.6</a></li>
    5004                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">4.4.4</a></li>
     4984                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">4.7.6</a></li>
     4985                        <li><em>Section 2.7</em>&nbsp;&nbsp;<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>
    50054986                        <li><em>Section 3.2.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    5009                         <li><em>Section 3.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.54">A.6</a></li>
    5011                         <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">7.1</a></li>
    5012                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">6.4.1</a></li>
    5013                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.26">3.1</a></li>
    5014                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">6.4.1</a></li>
    5016                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">3.2</a></li>
    5019                         <li><em>Section 5.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">3.2</a></li>
    5021                         <li><em>Section 5.5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">3.1</a></li>
    5023                         <li><em>Section 6.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">2.3.7</a></li>
    5027                         <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.53">13</a></li>
     4987                        <li><em>Section 3.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.1</a></li>
     4990                        <li><em>Section 3.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.56">A.6</a></li>
     4992                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">7.1</a></li>
     4993                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">6.4.1</a></li>
     4994                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">3.1</a></li>
     4995                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">6.4.1</a></li>
     4997                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">1.3.2</a></li>
     5000                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">3.2</a></li>
     5001                        <li><em>Section 5.3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">3.2</a></li>
     5003                        <li><em>Section 5.5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.27">3.1</a></li>
     5005                        <li><em>Section 6.2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">2.3.7</a></li>
     5009                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.55">13</a></li>
    50285010                     </ul>
    50295011                  </li>

  • draft-ietf-httpbis/experiment/p2-semantics.xml

    r1629 r1630  
    314314  <x:anchor-alias value="quoted-string"/>
    315315  <x:anchor-alias value="token"/>
     316  <x:anchor-alias value="word"/>
    316317  <x:anchor-alias value="BWS"/>
    317318  <x:anchor-alias value="OWS"/>
    … …  
    327328  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
    328329  <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
     330  <x:ref>word</x:ref>          = &lt;word, defined in &field-components;&gt;
    329331</artwork></figure>
    330332</section>
    … …  
    334336  <x:anchor-alias value="comment"/>
    335337  <x:anchor-alias value="partial-URI"/>
     338  <x:anchor-alias value="qvalue"/>
    336339  <x:anchor-alias value="URI-reference"/>
    337340<t>
    … …  
    342345  <x:ref>comment</x:ref>       = &lt;comment, defined in &field-components;&gt;
    343346  <x:ref>partial-URI</x:ref>   = &lt;partial-URI, defined in &uri;&gt;
     347  <x:ref>qvalue</x:ref>        = &lt;qvalue, defined in &qvalue;&gt;
    344348  <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in &uri;&gt;
    345349</artwork></figure>
    … …  
    55265530
    55275531<x:ref>MIME-Version</x:ref> = 1*DIGIT "." 1*DIGIT
    5528 
    55295532<x:ref>Max-Forwards</x:ref> = 1*DIGIT
    55305533
    … …  
    55325535
    55335536<x:ref>RWS</x:ref> = &lt;RWS, defined in [Part1], Section 3.2.1&gt;
    5534 
    55355537<x:ref>Referer</x:ref> = absolute-URI / partial-URI
    55365538<x:ref>Retry-After</x:ref> = HTTP-date / delta-seconds
    … …  
    55395541
    55405542<x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in [Part1], Section 2.7&gt;
    5541 
    55425543<x:ref>User-Agent</x:ref> = product *( RWS ( product / comment ) )
    55435544
    55445545<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [Part1], Section 2.7&gt;
    5545 
    55465546<x:ref>accept-ext</x:ref> = OWS ";" OWS token [ "=" word ]
    55475547<x:ref>accept-params</x:ref> = OWS ";" OWS "q=" qvalue *accept-ext
    5548 
    55495548<x:ref>asctime-date</x:ref> = day-name SP date3 SP time-of-day SP year
    55505549<x:ref>attribute</x:ref> = token
    55515550
    55525551<x:ref>charset</x:ref> = token
    5553 
    55545552<x:ref>codings</x:ref> = content-coding / "identity" / "*"
    5555 
    55565553<x:ref>comment</x:ref> = &lt;comment, defined in [Part1], Section 3.2.4&gt;
    55575554<x:ref>content-coding</x:ref> = token
    55585555
    55595556<x:ref>date1</x:ref> = day SP month SP year
    5560 
    55615557<x:ref>date2</x:ref> = day "-" month "-" 2DIGIT
    5562 
    55635558<x:ref>date3</x:ref> = month SP ( 2DIGIT / ( SP DIGIT ) )
    55645559<x:ref>day</x:ref> = 2DIGIT
    … …  
    55805575
    55815576<x:ref>expect-name</x:ref> = token
    5582 
    55835577<x:ref>expect-param</x:ref> = expect-name [ BWS "=" BWS expect-value ]
    5584 
    55855578<x:ref>expect-value</x:ref> = token / quoted-string
    55865579<x:ref>expectation</x:ref> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
    … …  
    55905583
    55915584<x:ref>language-range</x:ref> = &lt;language-range, defined in [RFC4647], Section 2.1&gt;
    5592 
    55935585<x:ref>language-tag</x:ref> = &lt;Language-Tag, defined in [RFC5646], Section 2.1&gt;
    55945586
    55955587<x:ref>mailbox</x:ref> = &lt;mailbox, defined in [RFC5322], Section 3.4&gt;
    5596 
    55975588<x:ref>media-range</x:ref> = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
    55985589 ";" OWS parameter )
    … …  
    56145605
    56155606<x:ref>obs-date</x:ref> = rfc850-date / asctime-date
    5616 
    56175607<x:ref>obs-text</x:ref> = &lt;obs-text, defined in [Part1], Section 3.2.4&gt;
    56185608
    56195609<x:ref>parameter</x:ref> = attribute "=" value
    5620 
    56215610<x:ref>partial-URI</x:ref> = &lt;partial-URI, defined in [Part1], Section 2.7&gt;
    5622 
    56235611<x:ref>product</x:ref> = token [ "/" product-version ]
    56245612<x:ref>product-version</x:ref> = token
    56255613
    56265614<x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in [Part1], Section 3.2.4&gt;
     5615<x:ref>qvalue</x:ref> = &lt;qvalue, defined in [Part1], Section 4.3.1&gt;
    56275616
    56285617<x:ref>reason-phrase</x:ref> = *( HTAB / SP / VCHAR / obs-text )
    5629 
    56305618<x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
    5631 
    56325619<x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT
    56335620
    56345621<x:ref>second</x:ref> = 2DIGIT
    5635 
    56365622<x:ref>status-code</x:ref> = 3DIGIT
    5637 
    56385623<x:ref>subtype</x:ref> = token
    56395624
    56405625<x:ref>time-of-day</x:ref> = hour ":" minute ":" second
    5641 
    56425626<x:ref>token</x:ref> = &lt;token, defined in [Part1], Section 3.2.4&gt;
    5643 
    56445627<x:ref>type</x:ref> = token
    56455628
    56465629<x:ref>value</x:ref> = word
     5630
     5631<x:ref>word</x:ref> = &lt;word, defined in [Part1], Section 3.2.4&gt;
    56475632
    56485633<x:ref>year</x:ref> = 4DIGIT
    … …  
    56505635</figure>
    56515636<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
    5652 ; qvalue UNDEFINED
    5653 ; word UNDEFINED
    56545637; Accept defined but not used
    56555638; Accept-Charset defined but not used

  • draft-ietf-httpbis/experiment/p3-payload.html

    r1627 r1630  
    407407      <link rel="Copyright" href="#rfc.copyrightnotice">
    408408      <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">
    412410      <link href="p2-semantics.html" rel="prev">
    413411      <link href="p4-conditional.html" rel="next">
    … …  
    487485      <ul class="toc">
    488486         <li>1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1"></a></li>
    489          <li>2.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    490                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    491                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    492             </ul>
    493          </li>
    494487         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    495          <li>A.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    496          <li>B.&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
     488         <li>A.&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
    497489      </ul>
    498490      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;
    499491      </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&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), March&nbsp;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&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), March&nbsp;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&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), March&nbsp;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&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), March&nbsp;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&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), March&nbsp;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&nbsp;1950, May&nbsp;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&nbsp;1951, May&nbsp;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&nbsp;1952, May&nbsp;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&nbsp;47, RFC&nbsp;4647, September&nbsp;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&nbsp;68, RFC&nbsp;5234, January&nbsp;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&nbsp;47, RFC&nbsp;5646, September&nbsp;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&nbsp;1945, May&nbsp;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&nbsp;2068, January&nbsp;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&nbsp;18, RFC&nbsp;2277, January&nbsp;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&nbsp;2295, March&nbsp;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&nbsp;2388, August&nbsp;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&nbsp;2616, June&nbsp;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&nbsp;63, RFC&nbsp;3629, November&nbsp;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&nbsp;90, RFC&nbsp;3864, September&nbsp;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&nbsp;13, RFC&nbsp;4288, December&nbsp;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&nbsp;26, RFC&nbsp;5226, May&nbsp;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&nbsp;5322, October&nbsp;2008.
    618             </td>
    619          </tr>
    620       </table>
    621       <div class="avoidbreak">
     492      <div id="rfc.figure.u.1"></div><pre class="inline">this = &lt;part does not have an ABNF anymore&gt;
     493</pre><div class="avoidbreak">
    622494         <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
    623495         <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span>
    … …  
    631503               <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>&nbsp;<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>
    632504      </div>
    633       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<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>&nbsp;<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>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     506      <div id="rfc.figure.u.2"></div> <pre class="inline">this = &lt;part does not have an ABNF anymore&gt;
    636507</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
    639509</pre></body>
    640510</html>

  • draft-ietf-httpbis/experiment/p3-payload.xml

    r1627 r1630  
    123123<section title="">
    124124<figure><artwork type="abnf2616">
    125 foo = bar
     125this = &lt;part does not have an ABNF anymore>
    126126</artwork></figure>
    127127</section>
    … …  
    129129<back>
    130130
    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 than
    255     this specification. On the other hand, this downward reference was
    256     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 also
    258     <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 than
    274     this specification. On the other hand, this downward reference was
    275     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 also
    277     <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 than
    305     this specification. On the other hand, this downward reference was
    306     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 also
    308     <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 
    608131<?BEGININC p3-payload.abnf-appendix ?>
    609132<section xmlns:x="http://purl.org/net/xml2rfc/ext" title="Collected ABNF" anchor="collected.abnf">
    610133<figure>
    611134<artwork type="abnf" name="p3-payload.parsed-abnf">
    612 foo = bar
     135this = &lt;part does not have an ABNF anymore&gt;
    613136</artwork>
    614137</figure>
    615138<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
    616 ; bar UNDEFINED
    617 ; foo defined but not used
     139; this defined but not used
    618140</artwork></figure></section>
    619141<?ENDINC p3-payload.abnf-appendix ?>

  • draft-ietf-httpbis/experiment/p4-conditional.html

    r1627 r1630  
    896896      </div>
    897897      <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<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="p3-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>):
    899899      </p>
    900900      <div id="rfc.figure.u.6"></div>
    … …  
    11231123         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.
    11241124      </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 11.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 200
     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 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
    11261126         response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires,
    11271127         or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
    … …  
    12451245      <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References
    12461246      </h2>
    1247       <table>             
     1247      <table>           
    12481248         <tr>
    12491249            <td class="reference"><b id="Part1">[Part1]</b></td>
    … …  
    12541254            <td class="reference"><b id="Part2">[Part2]</b></td>
    12551255            <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&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), March&nbsp;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&nbsp;draft-ietf-httpbis-p3-payload-latest (work in progress), March&nbsp;2012.
    12611256            </td>
    12621257         </tr>
    … …  
    14281423                     </ul>
    14291424                  </li>
    1430                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    14311426                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">1.2</a></li>
    1432                         <li><em>Section 11.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4.1</a></li>
    1433                      </ul>
    1434                   </li>
    1435                   <li><em>Part3</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">2.3.3</a></li>
    1437                         <li><em>Appendix </em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">2.3.3</a></li>
     1427                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
     1428                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1</a></li>
     1429                        <li><em>Section 10.13</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.3</a></li>
    14381430                     </ul>
    14391431                  </li>

  • draft-ietf-httpbis/experiment/p4-conditional.xml

    r1625 r1630  
    2424  <!ENTITY messaging                  "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    26   <!ENTITY header-accept-encoding     "<xref target='Part3' 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'/>">
    2727  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2828  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    3030  <!ENTITY http-date                  "<xref target='Part2' x:rel='#http.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3131  <!ENTITY transfer-codings           "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    32   <!ENTITY content-negotiation        "<xref target='Part3' 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'/>">
    3333]>
    3434<?rfc toc="yes" ?>
    … …  
    11911191</reference>
    11921192
    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 
    12141193<reference anchor="Part5">
    12151194  <front>

  • draft-ietf-httpbis/experiment/p6-cache.html

    r1627 r1630  
    987987         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    988988            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 11.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.
    990990         </li>
    991991      </ul>
    … …  
    21852185                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    21862186                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
    2187                         <li><em>Section 11.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
     2187                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
    21882188                     </ul>
    21892189                  </li>
Note: See TracChangeset for help on using the changeset viewer.