* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1494


Ignore:
Timestamp:
2011-12-16 13:11:53 (3 years ago)
Author:
julian.reschke@gmx.de
Message:

Simplify and correct Expect grammar; rephrase description (see #327)

Location:
draft-ietf-httpbis/latest
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/httpbis.abnf

    r1489 r1494  
    128128etagc = "!" / %x23-7E ; '#'-'~' 
    129129 / obs-text 
    130 expect-param = token [ "=" ( token / quoted-string ) ] 
    131 expectation = "100-continue" / expectation-extension 
    132 expectation-extension = token [ "=" ( token / quoted-string ) *( ";" expect-param ) ] 
     130expect-name = token 
     131expect-param = expect-name [ BWS "=" BWS expect-value ] 
     132expect-value = token / quoted-string 
     133expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ OWS expect-param ] ) 
    133134extension-pragma = token [ "=" ( token / quoted-string ) ] 
    134135field-content = *( HTAB / SP / VCHAR / obs-text ) 
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1493 r1494  
    359359  }  
    360360  @bottom-center { 
    361        content: "Expires June 17, 2012";  
     361       content: "Expires June 18, 2012";  
    362362  }  
    363363  @bottom-right { 
     
    411411      <meta name="dct.creator" content="Reschke, J. F."> 
    412412      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 
    413       <meta name="dct.issued" scheme="ISO8601" content="2011-12-15"> 
     413      <meta name="dct.issued" scheme="ISO8601" content="2011-12-16"> 
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    415415      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> 
     
    442442            </tr> 
    443443            <tr> 
    444                <td class="left">Expires: June 17, 2012</td> 
     444               <td class="left">Expires: June 18, 2012</td> 
    445445               <td class="right">HP</td> 
    446446            </tr> 
     
    495495            <tr> 
    496496               <td class="left"></td> 
    497                <td class="right">December 15, 2011</td> 
     497               <td class="right">December 16, 2011</td> 
    498498            </tr> 
    499499         </tbody> 
     
    525525         in progress”. 
    526526      </p> 
    527       <p>This Internet-Draft will expire on June 17, 2012.</p> 
     527      <p>This Internet-Draft will expire on June 18, 2012.</p> 
    528528      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    529529      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    757757      <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 
    758758      </p> 
    759       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
    760   <a href="#core.rules" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
    761   <a href="#core.rules" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
    762   <a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt; 
    763   <a href="#core.rules" class="smpl">token</a>         = &lt;token, 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.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt; 
     759      <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
     760  <a href="#core.rules" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
     761  <a href="#core.rules" class="smpl">RWS</a>           = &lt;RWS, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
     762  <a href="#core.rules" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt; 
     763  <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.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt; 
     764  <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.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt; 
    764765</pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 
    765766      <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 
    766       <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.10"><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; 
    767   <a href="#abnf.dependencies" class="smpl">comment</a>       = &lt;comment, 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#header.fields" title="Header Fields">Section 3.2</a>&gt; 
    768   <a href="#abnf.dependencies" class="smpl">partial-URI</a>   = &lt;partial-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; 
    769   <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, 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#product.tokens" title="Product Tokens">Section 5.2</a>&gt; 
    770   <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; 
     767      <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; 
     768  <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#header.fields" title="Header Fields">Section 3.2</a>&gt; 
     769  <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; 
     770  <a href="#abnf.dependencies" class="smpl">product</a>       = &lt;product, 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#product.tokens" title="Product Tokens">Section 5.2</a>&gt; 
     771  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, 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#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt; 
    771772</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1> 
    772       <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 4.3</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. 
     773      <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 4.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>). The method is case-sensitive. 
    773774      </p> 
    774775      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">Method</a>         = <a href="#core.rules" class="smpl">token</a> 
     
    849850         to a single application, so that this is clear. 
    850851      </p> 
    851       <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 
     852      <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.17"><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 
    852853         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 
    853854         can specify that only zero-length bodies (as opposed to absent bodies) are allowed. 
     
    858859      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h1> 
    859860      <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, 
    860          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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 
     861         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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 
    861862      </p> 
    862863      <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> 
     
    866867         with "X-" if they are to be registered (either immediately or in the future). 
    867868      </p> 
    868       <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 extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 
     869      <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 extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.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> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 
    869870         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>. 
    870871      </p> 
    871872      <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 
    872873         in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 
    873          quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.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>). 
     874         quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.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>). 
    874875      </p> 
    875876      <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 
     
    889890      <ul> 
    890891         <li> 
    891             <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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
     892            <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    892893            </p> 
    893894            <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible 
     
    905906         </li> 
    906907         <li> 
    907             <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 8.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>). 
     908            <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 8.1</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>). 
    908909            </p> 
    909910         </li> 
     
    916917         </li> 
    917918         <li> 
    918             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</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>). 
     919            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</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>). 
    919920            </p> 
    920921         </li> 
     
    967968               <tr> 
    968969                  <td class="left">Host</td> 
    969                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</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></td> 
     970                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</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></td> 
    970971               </tr> 
    971972               <tr> 
     
    10071008               <tr> 
    10081009                  <td class="left">TE</td> 
    1009                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</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></td> 
     1010                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.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></td> 
    10101011               </tr> 
    10111012               <tr> 
     
    10181019      <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> 
    10191020      <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 
    1020          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 4.3</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>). 
     1021         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 4.3</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>). 
    10211022      </p> 
    10221023      <div id="rfc.table.u.3"> 
     
    13401341         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 
    13411342      </p> 
    1342       <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.26"><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 
     1343      <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.27"><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 
    13431344         to ensure safe and proper transfer of the message. 
    13441345      </p> 
     
    13461347      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 
    13471348      <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> 
    1348       <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 4.3</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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 
     1349      <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 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>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 
    13491350         rules are used (with the first applicable one being selected): 
    13501351      </p> 
     
    15691570      </p> 
    15701571      <p id="rfc.section.6.8.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 
    1571          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 
     1572         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</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>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 
    15721573         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 
    15731574         infinite loop. 
    15741575      </p> 
    1575       <p id="rfc.section.6.8.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 9.3.1</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>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 
     1576      <p id="rfc.section.6.8.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 9.3.1</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>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 
    15761577      </p> 
    15771578      <div id="rfc.iref.c.1"></div> 
     
    15811582         forwarding of packets until the connection is closed. 
    15821583      </p> 
    1583       <p id="rfc.section.6.9.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 3.1.1.2</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>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 
     1584      <p id="rfc.section.6.9.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 3.1.1.2</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>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 
    15841585         For example, 
    15851586      </p> 
     
    16451646      <p id="rfc.section.7.1.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 
    16461647         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 
    1647          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.2.3</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 detailed discussion of the use and handling of this status code. 
     1648         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.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> for detailed discussion of the use and handling of this status code. 
    16481649      </p> 
    16491650      <div id="rfc.iref.23"></div> 
    16501651      <div id="rfc.iref.s.3"></div> 
    16511652      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 
    1652       <p id="rfc.section.7.1.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 8.7</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 a change in the application protocol being used on this connection. The server will switch protocols to those defined 
     1653      <p id="rfc.section.7.1.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 8.7</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 
    16531654         by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 
    16541655      </p> 
     
    17021703      <div id="rfc.iref.s.7"></div> 
    17031704      <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 
    1704       <p id="rfc.section.7.2.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.4</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>). Note that the behaviour 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>). 
     1705      <p id="rfc.section.7.2.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.4</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 behaviour 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>). 
    17051706      </p> 
    17061707      <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code 
     
    17371738         another input action. 
    17381739      </p> 
    1739       <p id="rfc.section.7.2.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.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 
     1740      <p id="rfc.section.7.2.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>. 
    17401741      </p> 
    17411742      <div id="rfc.iref.30"></div> 
     
    20382039      <div id="rfc.iref.s.37"></div> 
    20392040      <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 
    2040       <p id="rfc.section.7.4.19.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 8.7</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>) specifying the required protocols. 
     2041      <p id="rfc.section.7.4.19.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 8.7</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. 
    20412042      </p> 
    20422043      <div id="rfc.figure.u.8"></div>  
     
    20962097      <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 
    20972098         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 
    2098          in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</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>, 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. 
     2099         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. 
    20992100      </p> 
    21002101      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h1> 
     
    22332234      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2> 
    22342235      <p id="rfc.section.9.3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 
    2235       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a> 
     2236      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.expect" class="smpl">Expect</a>       = 1#<a href="#header.expect" class="smpl">expectation</a> 
    22362237   
    2237   <a href="#header.expect" class="smpl">expectation</a>  = "100-continue" / <a href="#header.expect" class="smpl">expectation-extension</a> 
    2238   <a href="#header.expect" class="smpl">expectation-extension</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) 
    2239                            *(";" <a href="#header.expect" class="smpl">expect-param</a>) ] 
    2240   <a href="#header.expect" class="smpl">expect-param</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ] 
    2241 </pre><p id="rfc.section.9.3.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status code. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code if any of the expectations cannot be met or, if there are other problems 
    2242          with the request, some other 4xx status code. 
    2243       </p> 
    2244       <p id="rfc.section.9.3.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing 
    2245          an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. 
    2246       </p> 
    2247       <p id="rfc.section.9.3.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive 
    2248          for quoted-string expectation-extensions. 
    2249       </p> 
    2250       <p id="rfc.section.9.3.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the 
    2251          Expect header field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 
    2252       </p> 
    2253       <p id="rfc.section.9.3.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 
    2254       <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</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> for the use of the 100 (Continue) status code. 
    2255       </p> 
     2238  <a href="#header.expect" class="smpl">expectation</a>  = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] 
     2239                             *( <a href="#core.rules" class="smpl">OWS</a> ";" [ <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">expect-param</a> ] ) 
     2240  <a href="#header.expect" class="smpl">expect-param</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] 
     2241   
     2242  <a href="#header.expect" class="smpl">expect-name</a>  = <a href="#core.rules" class="smpl">token</a> 
     2243  <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 
     2244</pre><p id="rfc.section.9.3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 
     2245         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 
     2246      </p> 
     2247      <p id="rfc.section.9.3.p.4">The only expectation defined by this specification is:</p> 
     2248      <p id="rfc.section.9.3.p.5"><span id="rfc.iref.93"></span><span id="rfc.iref.e.2"></span> 100-continue  
     2249      </p> 
     2250      <ul class="empty"> 
     2251         <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.2.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>. It does not support any expect-params. 
     2252         </li> 
     2253      </ul> 
     2254      <p id="rfc.section.9.3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 
     2255      <p id="rfc.section.9.3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 
     2256         field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 
     2257      </p> 
     2258      <p id="rfc.section.9.3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 
    22562259      <div id="rfc.iref.f.1"></div> 
    22572260      <div id="rfc.iref.h.5"></div> 
     
    22592262      <p id="rfc.section.9.4.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 
    22602263      </p> 
    2261       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a> 
     2264      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.from" class="smpl">From</a>    = <a href="#header.from" class="smpl">mailbox</a> 
    22622265   
    22632266  <a href="#header.from" class="smpl">mailbox</a> = &lt;mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>&gt; 
     
    22862289      <p id="rfc.section.9.5.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). 
    22872290      </p> 
    2288       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 
     2291      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 
    22892292</pre><div id="rfc.figure.u.24"></div>  
    22902293      <p>Examples are:</p>  <pre class="text">  Location: http://www.example.org/pub/WWW/People.html#tim 
     
    23102313         to trace a request which appears to be failing or looping in mid-chain. 
    23112314      </p> 
    2312       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 
     2315      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 
    23132316</pre><p id="rfc.section.9.6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 
    23142317      <p id="rfc.section.9.6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 
     
    23302333         non-HTTP URIs (e.g., FTP). 
    23312334      </p> 
    2332       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 
     2335      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 
    23332336</pre><p id="rfc.section.9.7.p.5">Example:</p> 
    23342337      <div id="rfc.figure.u.28"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html 
     
    23432346      </p> 
    23442347      <p id="rfc.section.9.8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 
    2345       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.32"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 
     2348      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 
    23462349</pre><div id="rule.delta-seconds"> 
    23472350         <p id="rfc.section.9.8.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p> 
    23482351      </div> 
    2349       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.33"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a> 
     2352      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#notation" class="smpl">DIGIT</a> 
    23502353</pre><p id="rfc.section.9.8.p.6">Two examples of its use are</p> 
    23512354      <div id="rfc.figure.u.31"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 
     
    23562359      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2> 
    23572360      <p id="rfc.section.9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 
    2358       <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.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>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
     2361      <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
    23592362         identifying the application. 
    23602363      </p> 
    2361       <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 
     2364      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.server" class="smpl">Server</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 
    23622365</pre><p id="rfc.section.9.9.p.4">Example:</p> 
    23632366      <div id="rfc.figure.u.33"></div><pre class="text">  Server: CERN/3.0 libwww/2.17 
    2364 </pre><p id="rfc.section.9.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 8.8</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>). 
     2367</pre><p id="rfc.section.9.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 8.8</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>). 
    23652368      </p> 
    23662369      <div class="note" id="rfc.section.9.9.p.7">  
     
    23782381         user agent limitations. 
    23792382      </p> 
    2380       <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.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>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 
     2383      <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.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>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 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>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 
    23812384         for identifying the application. 
    23822385      </p> 
     
    23892392         doing so makes the field value more difficult to parse. 
    23902393      </p> 
    2391       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.35"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 
     2394      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span>  <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#abnf.dependencies" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 
    23922395</pre><p id="rfc.section.9.10.p.7">Example:</p> 
    23932396      <div id="rfc.figure.u.35"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3 
     
    28502853      </p> 
    28512854      <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1> 
    2852       <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>. 
     2855      <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>. 
    28532856      </p> 
    28542857      <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References 
     
    30103013      </p> 
    30113014      <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 
    3012          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>) 
     3015         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>) 
    30133016      </p> 
    30143017      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 
    30153018      <div id="rfc.figure.u.36"></div> <pre class="inline"><a href="#header.allow" class="smpl">Allow</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 
     3019 
     3020<a href="#core.rules" class="smpl">BWS</a> = &lt;BWS, defined in [Part1], Section 1.2.2&gt; 
    30163021 
    30173022<a href="#header.date" class="smpl">Date</a> = HTTP-date 
     
    30683073<a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*DIGIT 
    30693074 
    3070 <a href="#header.expect" class="smpl">expect-param</a> = token [ "=" ( token / quoted-string ) ] 
    3071 <a href="#header.expect" class="smpl">expectation</a> = "100-continue" / expectation-extension 
    3072 <a href="#header.expect" class="smpl">expectation-extension</a> = token [ "=" ( token / quoted-string ) *( ";" 
    3073  expect-param ) ] 
     3075<a href="#header.expect" class="smpl">expect-name</a> = token 
     3076<a href="#header.expect" class="smpl">expect-param</a> = expect-name [ BWS "=" BWS expect-value ] 
     3077<a href="#header.expect" class="smpl">expect-value</a> = token / quoted-string 
     3078<a href="#header.expect" class="smpl">expectation</a> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ 
     3079 OWS expect-param ] ) 
    30743080 
    30753081<a href="#preferred.date.format" class="smpl">hour</a> = 2DIGIT 
     
    34063412         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/312">http://tools.ietf.org/wg/httpbis/trac/ticket/312</a>&gt;: "should there be a permanent variant of 307" 
    34073413         </li> 
     3414         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/327">http://tools.ietf.org/wg/httpbis/trac/ticket/327</a>&gt;: "'expect' grammar missing OWS" 
     3415         </li> 
    34083416         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/329">http://tools.ietf.org/wg/httpbis/trac/ticket/329</a>&gt;: "header field considerations: quoted-string vs use of double quotes" 
    34093417         </li> 
     
    34163424            <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 
    34173425                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.22"><b>7.1.1</b></a>, <a href="#rfc.xref.status.100.2">10.2</a></li> 
     3426                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.93"><b>9.3</b></a></li> 
    34183427                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.23"><b>7.1.2</b></a>, <a href="#rfc.xref.status.101.2">10.2</a></li> 
    34193428               </ul> 
     
    34863495            <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 
    34873496                  <li>Expect header field&nbsp;&nbsp;<a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">7.4.18</a>, <a href="#rfc.iref.e.1"><b>9.3</b></a>, <a href="#rfc.xref.header.expect.3">10.3</a></li> 
     3497                  <li>Expect Values&nbsp;&nbsp; 
     3498                     <ul> 
     3499                        <li>100-continue&nbsp;&nbsp;<a href="#rfc.iref.e.2"><b>9.3</b></a></li> 
     3500                     </ul> 
     3501                  </li> 
    34883502               </ul> 
    34893503            </li> 
     
    35033517                        <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>8</b></a></li> 
    35043518                        <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>8</b></a></li> 
    3505                         <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>9.8</b></a></li> 
     3519                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>9.8</b></a></li> 
    35063520                        <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.24"><b>9.3</b></a></li> 
    3507                         <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>9.3</b></a></li> 
     3521                        <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>9.3</b></a></li> 
     3522                        <li><tt>expect-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>9.3</b></a></li> 
     3523                        <li><tt>expect-value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>9.3</b></a></li> 
    35083524                        <li><tt>expectation</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>9.3</b></a></li> 
    3509                         <li><tt>expectation-extension</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>9.3</b></a></li> 
    35103525                        <li><tt>extension-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>4</b></a></li> 
    3511                         <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>9.4</b></a></li> 
     3526                        <li><tt>From</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>9.4</b></a></li> 
    35123527                        <li><tt>GMT</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.18"><b>8</b></a></li> 
    35133528                        <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.10"><b>8</b></a></li> 
    35143529                        <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>8</b></a></li> 
    3515                         <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>9.5</b></a></li> 
    3516                         <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>9.6</b></a></li> 
     3530                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>9.5</b></a></li> 
     3531                        <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>9.6</b></a></li> 
    35173532                        <li><tt>Method</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2</b></a></li> 
    35183533                        <li><tt>minute</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.11"><b>8</b></a></li> 
     
    35203535                        <li><tt>obs-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.19"><b>8</b></a></li> 
    35213536                        <li><tt>Reason-Phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>4</b></a></li> 
    3522                         <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>9.7</b></a></li> 
    3523                         <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>9.8</b></a></li> 
     3537                        <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.32"><b>9.7</b></a></li> 
     3538                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>9.8</b></a></li> 
    35243539                        <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>8</b></a></li> 
    35253540                        <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.20"><b>8</b></a></li> 
    35263541                        <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>8</b></a></li> 
    3527                         <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.34"><b>9.9</b></a></li> 
     3542                        <li><tt>Server</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>9.9</b></a></li> 
    35283543                        <li><tt>Status-Code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>4</b></a></li> 
    35293544                        <li><tt>time-of-day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>8</b></a></li> 
    3530                         <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>9.10</b></a></li> 
     3545                        <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>9.10</b></a></li> 
    35313546                        <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.17"><b>8</b></a></li> 
    35323547                     </ul> 
     
    35813596            </li> 
    35823597            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 
    3583                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.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">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.19</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">9.3</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul> 
     3598                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</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.2</a>, <a href="#rfc.xref.Part1.25">3.2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.28">5.1</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.8</a>, <a href="#rfc.xref.Part1.31">6.9</a>, <a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.2.4</a>, <a href="#rfc.xref.Part1.35">7.2.6</a>, <a href="#rfc.xref.Part1.36">7.4.19</a>, <a href="#rfc.xref.Part1.37">7.5.6</a>, <a href="#rfc.xref.Part1.38">9.3</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">9.10</a>, <a href="#rfc.xref.Part1.44">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.45">A</a><ul> 
    35843599                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li> 
    3585                         <li><em>Section 1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3.1</a></li> 
    3586                         <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 
     3600                        <li><em>Section 1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">3.1</a></li> 
     3601                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a></li> 
    35873602                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.1</a></li> 
    3588                         <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.2.4</a></li> 
    3589                         <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.36">7.5.6</a></li> 
    3590                         <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 
    3591                         <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.9</a></li> 
    3592                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 
    3593                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 
    3594                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> 
    3595                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 
    3596                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li> 
    3597                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li> 
    3598                         <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">9.3</a></li> 
    3599                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li> 
    3600                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li> 
    3601                         <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li> 
    3602                         <li><em>Section 8.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li> 
    3603                         <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.44">A</a></li> 
    3604                         <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li> 
    3605                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.43">12</a></li> 
     3603                        <li><em>Section 2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">7.2.4</a></li> 
     3604                        <li><em>Section 2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">7.5.6</a></li> 
     3605                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.15">1.2.2</a></li> 
     3606                        <li><em>Section 3.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">6.9</a></li> 
     3607                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.18">3</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.43">9.10</a></li> 
     3608                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.1</a>, <a href="#rfc.xref.Part1.20">3.1</a></li> 
     3609                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.27">5</a>, <a href="#rfc.xref.Part1.35">7.2.6</a></li> 
     3610                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.26">3.3</a>, <a href="#rfc.xref.Part1.28">5.1</a></li> 
     3611                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.1</a></li> 
     3612                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 
     3613                        <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">9.3</a></li> 
     3614                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li> 
     3615                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li> 
     3616                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">3.2</a></li> 
     3617                        <li><em>Section 8.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.19</a></li> 
     3618                        <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.41">9.9</a>, <a href="#rfc.xref.Part1.45">A</a></li> 
     3619                        <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.8</a></li> 
     3620                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.44">12</a></li> 
    36063621                     </ul> 
    36073622                  </li> 
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1493 r1494  
    365365  <x:anchor-alias value="quoted-string"/> 
    366366  <x:anchor-alias value="token"/> 
     367  <x:anchor-alias value="BWS"/> 
    367368  <x:anchor-alias value="OWS"/> 
    368369  <x:anchor-alias value="RWS"/> 
     
    371372</t> 
    372373<figure><artwork type="abnf2616"> 
     374  <x:ref>BWS</x:ref>           = &lt;BWS, defined in &basic-rules;&gt; 
    373375  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &basic-rules;&gt; 
    374376  <x:ref>RWS</x:ref>           = &lt;RWS, defined in &basic-rules;&gt; 
     
    25792581  <x:anchor-alias value="Expect"/> 
    25802582  <x:anchor-alias value="expectation"/> 
    2581   <x:anchor-alias value="expectation-extension"/> 
    25822583  <x:anchor-alias value="expect-param"/> 
     2584  <x:anchor-alias value="expect-name"/> 
     2585  <x:anchor-alias value="expect-value"/> 
    25832586<t> 
    25842587   The "Expect" header field is used to indicate that particular 
    25852588   server behaviors are required by the client. 
    25862589</t> 
    2587 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expectation-extension"/><iref primary="true" item="Grammar" subitem="expect-param"/> 
     2590<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/> 
    25882591  <x:ref>Expect</x:ref>       = 1#<x:ref>expectation</x:ref> 
    25892592   
    2590   <x:ref>expectation</x:ref>  = "100-continue" / <x:ref>expectation-extension</x:ref> 
    2591   <x:ref>expectation-extension</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) 
    2592                            *(";" <x:ref>expect-param</x:ref>) ] 
    2593   <x:ref>expect-param</x:ref> = <x:ref>token</x:ref> [ "=" ( <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> ) ] 
     2593  <x:ref>expectation</x:ref>  = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ] 
     2594                             *( <x:ref>OWS</x:ref> ";" [ <x:ref>OWS</x:ref> <x:ref>expect-param</x:ref> ] ) 
     2595  <x:ref>expect-param</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ] 
     2596   
     2597  <x:ref>expect-name</x:ref>  = <x:ref>token</x:ref> 
     2598  <x:ref>expect-value</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref> 
    25942599</artwork></figure> 
    25952600<t> 
    2596    A server that does not understand or is unable to comply with any of 
    2597    the expectation values in the Expect field of a request &MUST; respond 
    2598    with appropriate error status code. The server &MUST; respond with a 417 
    2599    (Expectation Failed) status code if any of the expectations cannot be met 
    2600    or, if there are other problems with the request, some other 4xx 
    2601    status code. 
    2602 </t> 
    2603 <t> 
    2604    This header field is defined with extensible syntax to allow for 
    2605    future extensions. If a server receives a request containing an 
    2606    Expect field that includes an expectation-extension that it does not 
    2607    support, it &MUST; respond with a 417 (Expectation Failed) status code. 
    2608 </t> 
    2609 <t> 
    2610    Comparison of expectation values is case-insensitive for unquoted 
    2611    tokens (including the 100-continue token), and is case-sensitive for 
    2612    quoted-string expectation-extensions. 
    2613 </t> 
    2614 <t> 
    2615    The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy &MUST; 
    2616    return a 417 (Expectation Failed) status code if it receives a request 
    2617    with an expectation that it cannot meet. However, the Expect 
    2618    header field itself is end-to-end; it &MUST; be forwarded if the 
    2619    request is forwarded. 
    2620 </t> 
    2621 <t> 
    2622    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the 
    2623    Expect header field. 
    2624 </t> 
    2625 <t> 
    2626    See &use100; for the use of the 100 (Continue) status code. 
     2601   If all received Expect header field(s) are syntactically valid but contain 
     2602   an expectation that the recipient does not understand or cannot comply with, 
     2603   the recipient &MUST; respond with a 417 (Expectation Failed) status code. A 
     2604   recipient of a syntactically invalid Expectation header field &MUST; respond 
     2605   with a 4xx status code other than 417. 
     2606</t> 
     2607<t> 
     2608   The only expectation defined by this specification is: 
     2609</t> 
     2610<t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/> 
     2611  100-continue 
     2612   <list> 
     2613      <t> 
     2614        The "100-continue" expectation is defined &use100;. It does not support 
     2615        any expect-params. 
     2616      </t> 
     2617   </list> 
     2618</t> 
     2619<t> 
     2620   Comparison is case-insensitive for names (expect-name), and case-sensitive 
     2621   for values (expect-value). 
     2622</t> 
     2623<t> 
     2624   The Expect mechanism is hop-by-hop: the above requirements apply to any 
     2625   server, including proxies. However, the Expect header field itself is 
     2626   end-to-end; it &MUST; be forwarded if the request is forwarded. 
     2627</t> 
     2628<t> 
     2629   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect 
     2630   header field. 
    26272631</t> 
    26282632</section> 
     
    40334037<x:ref>Allow</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 
    40344038 
     4039<x:ref>BWS</x:ref> = &lt;BWS, defined in [Part1], Section 1.2.2&gt; 
     4040 
    40354041<x:ref>Date</x:ref> = HTTP-date 
    40364042 
     
    40864092<x:ref>delta-seconds</x:ref> = 1*DIGIT 
    40874093 
    4088 <x:ref>expect-param</x:ref> = token [ "=" ( token / quoted-string ) ] 
    4089 <x:ref>expectation</x:ref> = "100-continue" / expectation-extension 
    4090 <x:ref>expectation-extension</x:ref> = token [ "=" ( token / quoted-string ) *( ";" 
    4091  expect-param ) ] 
     4094<x:ref>expect-name</x:ref> = token 
     4095<x:ref>expect-param</x:ref> = expect-name [ BWS "=" BWS expect-value ] 
     4096<x:ref>expect-value</x:ref> = token / quoted-string 
     4097<x:ref>expectation</x:ref> = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [ 
     4098 OWS expect-param ] ) 
    40924099 
    40934100<x:ref>hour</x:ref> = 2DIGIT 
     
    47084715    </t> 
    47094716    <t> 
     4717      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/327"/>: 
     4718      "'expect' grammar missing OWS" 
     4719    </t> 
     4720    <t> 
    47104721      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/329"/>: 
    47114722      "header field considerations: quoted-string vs use of double quotes" 
Note: See TracChangeset for help on using the changeset viewer.