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.

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

Legend:

Unmodified
Added
Removed

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

    r1589 r1590  
    756756      <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and
    757757         MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the
    758          Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource and relationships between resources. Messages are passed in a format similar to that used
    759          by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
     758         Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).
    760759      </p>
    761760      <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented
    … …  
    873872         and response structures onto the data units of the underlying transport protocol is outside the scope of this specification.
    874873      </p>
    875       <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's
    876          URI. For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
     874      <p id="rfc.section.2.2.p.2">The specific connection protocols to be used for an interaction are determined by client configuration and the target URI
     875         (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>). For example, the "http" URI scheme (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use
    877876         a proxy via some other connection port or protocol instead of using the defaults.
    878877      </p>
    … …  
    10531052</pre><p id="rfc.section.2.7.p.4">Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows
    10541053         any form of reference (URI-reference), only a URI in absolute form (absolute-URI), only the path and optional query components,
    1055          or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the request's target URI
    1056          (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>), if known by the recipient, or the effective request URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
     1054         or some combination of the above. Unless otherwise indicated, URI references are parsed relative to the effective request
     1055         URI (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>).
    10571056      </p>
    10581057      <h3 id="rfc.section.2.7.1"><a href="#rfc.section.2.7.1">2.7.1</a>&nbsp;<a id="http.uri" href="#http.uri">http URI scheme</a></h3>
    … …  
    18791878         from this reconstruction process is referred to as the "effective request URI".
    18801879      </p>
    1881       <p id="rfc.section.5.5.p.2">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the
     1880      <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
     1881      <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the
    18821882         effective request URI is constructed as follows.
    18831883      </p>
    1884       <p id="rfc.section.5.5.p.3">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
     1884      <p id="rfc.section.5.5.p.4">If the request is received over an SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
    18851885         the scheme is "http".
    18861886      </p>
    1887       <p id="rfc.section.5.5.p.4">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.
     1887      <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.
    18881888         Otherwise, if a Host header field is supplied with a non-empty field-value, then the authority component is the same as the
    18891889         Host field-value. Otherwise, the authority component is the concatenation of the default hostname configured for the server,
    18901890         a colon (":"), and the connection's incoming TCP port number in decimal form.
    18911891      </p>
    1892       <p id="rfc.section.5.5.p.5">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component
     1892      <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component
    18931893         is empty. Otherwise, the combined path and query component is the same as the request-target.
    18941894      </p>
    1895       <p id="rfc.section.5.5.p.6">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating
     1895      <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating
    18961896         the scheme, "://", authority, and combined path and query component.
    18971897      </p>
    … …  
    19061906</pre> <div id="rfc.figure.u.58"></div>
    19071907      <p>has an effective request URI of</p>  <pre class="text">https://www.example.org
    1908 </pre> <p id="rfc.section.5.5.p.11">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI.
    1909       </p>
    1910       <p id="rfc.section.5.5.p.12">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess
     1908</pre> <p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the Host field-value and instead replace it with a configured server name when constructing the effective request URI.
     1909      </p>
     1910      <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a Host header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess
    19111911         the effective request URI's authority component.
    19121912      </p>

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1589 r1590  
    162162   message payloads for flexible interaction with network-based hypertext
    163163   information systems. HTTP relies upon the Uniform Resource Identifier (URI)
    164    standard <xref target="RFC3986"/> to indicate the target resource and
    165    relationships between resources.
     164   standard <xref target="RFC3986"/> to indicate the target resource
     165   (<xref target="target-resource"/>) and relationships between resources.
    166166   Messages are passed in a format similar to that used by Internet mail
    167167   <xref target="RFC5322"/> and the Multipurpose Internet Mail Extensions
    … …  
    397397<t>
    398398   The specific connection protocols to be used for an interaction
    399    are determined by client configuration and the target resource's URI.
     399   are determined by client configuration and the target URI
     400   (<xref target="target-resource"/>).
    400401   For example, the "http" URI scheme
    401402   (<xref target="http.uri"/>) indicates a default connection of TCP
    … …  
    780781   path and optional query components, or some combination of the above.
    781782   Unless otherwise indicated, URI references are parsed
    782    relative to the request's target URI (<xref target="target-resource"/>),
    783    if known by the recipient, or the effective request URI
     783   relative to the effective request URI
    784784   (<xref target="effective.request.uri"/>).
    785785</t>
    … …  
    24252425   The URI derived from this reconstruction process is referred to as the
    24262426   "effective request URI".
     2427</t>
     2428<t>
     2429   For a user agent, the effective request URI is the target URI.
    24272430</t>
    24282431<t>

  • 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>

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

    r1586 r1590  
    19951995   itself), or when the server is under attack by a client attempting to
    19961996   exploit security holes present in some servers using fixed-length
    1997    buffers for reading or manipulating the effective request URI.
     1997   buffers for reading or manipulating the request-target.
    19981998</t>
    19991999</section>
    … …  
    26272627<t>
    26282628   The "Referer" [sic] header field allows the client to specify the
    2629    URI of the resource from which the effective request URI was obtained (the
     2629   URI of the resource from which the target URI was obtained (the
    26302630   "referrer", although the header field is misspelled.).
    26312631</t>
    … …  
    26392639</t>
    26402640<t>
    2641    If the effective request URI was obtained from a source that does not have its own
     2641   If the target URI was obtained from a source that does not have its own
    26422642   URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    26432643   sent with the value "about:blank", or not be sent at all. Note that this
Note: See TracChangeset for help on using the changeset viewer.