Ignore:
Timestamp:
Mar 12, 2012, 2:15:20 AM (8 years ago)
Author:
fielding@…
Message:

on second thought, it is better to just define what effective request URI means for a user agent. plus, add more xrefs.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1580 r1590  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 11, 2012";
     462       content: "Expires September 13, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    504504      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    505505      <meta name="dct.creator" content="Fielding, R.">
    506       <meta name="dct.creator" content="Gettys, J.">
    507       <meta name="dct.creator" content="Mogul, J.">
    508       <meta name="dct.creator" content="Frystyk, H.">
    509       <meta name="dct.creator" content="Masinter, L.">
    510       <meta name="dct.creator" content="Leach, P.">
    511       <meta name="dct.creator" content="Berners-Lee, T.">
    512506      <meta name="dct.creator" content="Lafon, Y.">
    513507      <meta name="dct.creator" content="Reschke, J. F.">
    514508      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    515       <meta name="dct.issued" scheme="ISO8601" content="2012-03-10">
     509      <meta name="dct.issued" scheme="ISO8601" content="2012-03-12">
    516510      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    517511      <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.">
    … …  
    532526               <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
    533527               </td>
    534                <td class="right">J. Gettys</td>
     528               <td class="right">Y. Lafon, Editor</td>
    535529            </tr>
    536530            <tr>
    537531               <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2817">2817</a> (if approved)
    538532               </td>
    539                <td class="right">Alcatel-Lucent</td>
     533               <td class="right">W3C</td>
    540534            </tr>
    541535            <tr>
    542536               <td class="left">Intended status: Standards Track</td>
    543                <td class="right">J. Mogul</td>
    544             </tr>
    545             <tr>
    546                <td class="left">Expires: September 11, 2012</td>
    547                <td class="right">HP</td>
    548             </tr>
    549             <tr>
    550                <td class="left"></td>
    551                <td class="right">H. Frystyk</td>
    552             </tr>
    553             <tr>
    554                <td class="left"></td>
    555                <td class="right">Microsoft</td>
    556             </tr>
    557             <tr>
    558                <td class="left"></td>
    559                <td class="right">L. Masinter</td>
    560             </tr>
    561             <tr>
    562                <td class="left"></td>
    563                <td class="right">Adobe</td>
    564             </tr>
    565             <tr>
    566                <td class="left"></td>
    567                <td class="right">P. Leach</td>
    568             </tr>
    569             <tr>
    570                <td class="left"></td>
    571                <td class="right">Microsoft</td>
    572             </tr>
    573             <tr>
    574                <td class="left"></td>
    575                <td class="right">T. Berners-Lee</td>
    576             </tr>
    577             <tr>
    578                <td class="left"></td>
    579                <td class="right">W3C/MIT</td>
    580             </tr>
    581             <tr>
    582                <td class="left"></td>
    583                <td class="right">Y. Lafon, Editor</td>
    584             </tr>
    585             <tr>
    586                <td class="left"></td>
    587                <td class="right">W3C</td>
    588             </tr>
    589             <tr>
    590                <td class="left"></td>
    591537               <td class="right">J. Reschke, Editor</td>
    592538            </tr>
    593539            <tr>
    594                <td class="left"></td>
     540               <td class="left">Expires: September 13, 2012</td>
    595541               <td class="right">greenbytes</td>
    596542            </tr>
    597543            <tr>
    598544               <td class="left"></td>
    599                <td class="right">March 10, 2012</td>
     545               <td class="right">March 12, 2012</td>
    600546            </tr>
    601547         </tbody>
    … …  
    627573         in progress”.
    628574      </p>
    629       <p>This Internet-Draft will expire on September 11, 2012.</p>
     575      <p>This Internet-Draft will expire on September 13, 2012.</p>
    630576      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    631577      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    865811  <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;
    866812</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    867       <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.6</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.
     813      <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.
    868814      </p>
    869815      <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>
    … …  
    1000946         </li>
    1001947         <li>
    1002             <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>).
     948            <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    1003949            </p>
    1004950         </li>
    … …  
    11021048               <tr>
    11031049                  <td class="left">TE</td>
    1104                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.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>
     1050                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.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>
    11051051               </tr>
    11061052               <tr>
    … …  
    11131059      <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>
    11141060      <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
    1115          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.6</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>).
     1061         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.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    11161062      </p>
    11171063      <div id="rfc.table.u.3">
    … …  
    14411387      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    14421388      <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>
    1443       <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.6</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
     1389      <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.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
    14441390         rules are used (with the first applicable one being selected):
    14451391      </p>
    … …  
    16621608      </p>
    16631609      <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
    1664          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.3</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
     1610         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.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
    16651611         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    16661612         infinite loop.
    16671613      </p>
    1668       <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.
     1614      <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 7.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.
    16691615      </p>
    16701616      <div id="rfc.iref.c.1"></div>
    … …  
    17401686      <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
    17411687         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
    1742          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.
     1688         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.
    17431689      </p>
    17441690      <div id="rfc.iref.23"></div>
    17451691      <div id="rfc.iref.s.3"></div>
    17461692      <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>
    1747       <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.2</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
     1693      <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 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
    17481694         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    17491695      </p>
    … …  
    20762022         query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
    20772023         points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
    2078          in some servers using fixed-length buffers for reading or manipulating the effective request URI.
     2024         in some servers using fixed-length buffers for reading or manipulating the request-target.
    20792025      </p>
    20802026      <div id="rfc.iref.49"></div>
    … …  
    20932039      <div id="rfc.iref.s.31"></div>
    20942040      <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2095       <p id="rfc.section.7.4.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 8.2</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.
     2041      <p id="rfc.section.7.4.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.
    20962042      </p>
    20972043      <div id="rfc.figure.u.8"></div>
    … …  
    23182264      </p>
    23192265      <ul class="empty">
    2320          <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.
     2266         <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.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.
    23212267         </li>
    23222268      </ul>
    … …  
    23932339      <div id="rfc.iref.h.8"></div>
    23942340      <h2 id="rfc.section.10.7"><a href="#rfc.section.10.7">10.7</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    2395       <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the effective request URI
    2396          was obtained (the "referrer", although the header field is misspelled.).
     2341      <p id="rfc.section.10.7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained
     2342         (the "referrer", although the header field is misspelled.).
    23972343      </p>
    23982344      <p id="rfc.section.10.7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,
    … …  
    24002346         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    24012347      </p>
    2402       <p id="rfc.section.10.7.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
    2403          the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
     2348      <p id="rfc.section.10.7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer
     2349         field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
    24042350         non-HTTP URIs (e.g., FTP).
    24052351      </p>
    … …  
    24362382</pre><p id="rfc.section.10.9.p.4">Example:</p>
    24372383      <div id="rfc.figure.u.35"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2438 </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 8.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>).
     2384</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.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    24392385      </p>
    24402386      <div class="note" id="rfc.section.10.9.p.7">
    … …  
    29222868      </p>
    29232869      <h1 id="rfc.section.13"><a href="#rfc.section.13">13.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
    2924       <p id="rfc.section.13.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</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>.
     2870      <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.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    29252871      </p>
    29262872      <h1 id="rfc.references"><a id="rfc.section.14" href="#rfc.section.14">14.</a> References
    … …  
    29312877         <tr>
    29322878            <td class="reference"><b id="Part1">[Part1]</b></td>
    2933             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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.
     2879            <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.
    29342880            </td>
    29352881         </tr>
    29362882         <tr>
    29372883            <td class="reference"><b id="Part3">[Part3]</b></td>
    2938             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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.
     2884            <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.
    29392885            </td>
    29402886         </tr>
    29412887         <tr>
    29422888            <td class="reference"><b id="Part4">[Part4]</b></td>
    2943             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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.
     2889            <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.
    29442890            </td>
    29452891         </tr>
    29462892         <tr>
    29472893            <td class="reference"><b id="Part5">[Part5]</b></td>
    2948             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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.
     2894            <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.
    29492895            </td>
    29502896         </tr>
    29512897         <tr>
    29522898            <td class="reference"><b id="Part6">[Part6]</b></td>
    2953             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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.
     2899            <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.
    29542900            </td>
    29552901         </tr>
    29562902         <tr>
    29572903            <td class="reference"><b id="Part7">[Part7]</b></td>
    2958             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</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-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), March&nbsp;2012.
     2904            <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-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), March&nbsp;2012.
    29592905            </td>
    29602906         </tr>
    … …  
    30342980               (editor)
    30352981               <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:fielding@gbiv.com"><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address>
    3036          <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">Alcatel-Lucent Bell Labs</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:jg@freedesktop.org"><span class="email">jg@freedesktop.org</span></a></span><span class="vcardline">URI: <a href="http://gettys.wordpress.com/" class="url">http://gettys.wordpress.com/</a></span></address>
    3037          <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:JeffMogul@acm.org"><span class="email">JeffMogul@acm.org</span></a></span></address>
    3038          <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:henrikn@microsoft.com"><span class="email">henrikn@microsoft.com</span></a></span></address>
    3039          <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:LMM@acm.org"><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address>
    3040          <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span></span><span class="vcardline">Email: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address>
    3041          <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address>
    30422982         <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span>
    30432983               (editor)
    … …  
    30873027      </p>
    30883028      <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3089          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;10.9</a>)
     3029         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.43"><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>)
    30903030      </p>
    30913031      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    37053645                        <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.35">7.2.6</a></li>
    37063646                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    3707                         <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3647                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
    37083648                        <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.2</a>, <a href="#rfc.xref.Part1.31">6.9</a></li>
    37093649                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
    3710                         <li><em>Section 5.6</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>
    3711                         <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">10.3</a></li>
    3712                         <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
    3713                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li>
    3714                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>
    3715                         <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.8</a></li>
    3716                         <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">13</a></li>
     3650                        <li><em>Section 5.5</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>
     3651                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
     3652                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.40">10.9</a>, <a href="#rfc.xref.Part1.43">A</a></li>
     3653                        <li><em>Section 6.4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.1</a>, <a href="#rfc.xref.Part1.38">10.3</a></li>
     3654                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.33">7.1.2</a>, <a href="#rfc.xref.Part1.36">7.4.15</a></li>
     3655                        <li><em>Section 7.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.30">6.8</a></li>
     3656                        <li><em>Section 9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.42">13</a></li>
    37173657                     </ul>
    37183658                  </li>
Note: See TracChangeset for help on using the changeset viewer.