Changeset 2563


Ignore:
Timestamp:
19/01/14 09:51:24 (6 years ago)
Author:
fielding@…
Message:

(editorial) remove usage of We; move definition of transforming proxy into the only section that uses it, removing the need for non-transforming proxy to be defined; clean up redundant paragraphs in description of cache-control extensions; see #531

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2561 r2563  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 22, 2014";
     450       content: "Expires July 23, 2014";
    451451  }
    452452  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
     492      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">January 18, 2014</td>
     521               <td class="right">January 19, 2014</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: July 22, 2014</td>
     524               <td class="left">Expires: July 23, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
     
    551551            in progress”.
    552552         </p>
    553          <p>This Internet-Draft will expire on July 22, 2014.</p>
     553         <p>This Internet-Draft will expire on July 23, 2014.</p>
    554554      </div>
    555555      <div id="rfc.copyrightnotice">
     
    814814            <div id="rfc.iref.r.1"></div>
    815815            <p id="rfc.section.2.1.p.2">The terms client and server refer only to the roles that these programs perform for a particular connection. The same program
    816                might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders
    817                (web-based robots), command-line tools, native applications, and mobile apps. The term "<dfn>origin server</dfn>" is used to refer to the program that can originate authoritative responses to a request. For general requirements, we use
    818                the terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" to refer to any component that sends or receives, respectively, a given message.
     816               might act as a client on some connections and a server on others. The term "<dfn>user agent</dfn>" refers to any of the various client programs that initiate a request, including (but not limited to) browsers, spiders (web-based
     817               robots), command-line tools, custom applications, and mobile apps. The term "<dfn>origin server</dfn>" refers to the program that can originate authoritative responses for a given target resource. The terms "<dfn>sender</dfn>" and "<dfn>recipient</dfn>" refer to any implementation that sends or receives a given message, respectively.
    819818            </p>
    820819            <p id="rfc.section.2.1.p.3">HTTP relies upon the Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section&nbsp;5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the differences between HTTP and MIME messages).
     
    871870               given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.
    872871            </p>
    873             <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user
    874                or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting
    875                of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise,
    876                requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices,
    877                run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption
     872            <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that not all user agents can make interactive suggestions to their user or provide
     873               adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors
     874               to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements
     875               that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time
     876               options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption
    878877               of normal processing if the user has already made that choice.
    879878            </p>
     
    897896               often based on dynamic configuration for load balancing.
    898897            </p>
    899             <p id="rfc.section.2.3.p.4"><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" to describe various requirements in relation to the directional flow of a message: all messages flow from upstream to downstream.
    900                Likewise, we use the terms inbound and outbound to refer to directions in relation to the request path: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
     898            <p id="rfc.section.2.3.p.4"><span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span> <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> The terms "<dfn>upstream</dfn>" and "<dfn>downstream</dfn>" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream.
     899               The terms inbound and outbound are used to describe directional requirements in relation to the request route: "<dfn>inbound</dfn>" means toward the origin server and "<dfn>outbound</dfn>" means toward the user agent.
    901900            </p>
    902901            <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "<dfn>proxy</dfn>" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive requests
     
    904903               are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
    905904               different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
    906                for the sake of security, annotation services, or shared caching.
    907             </p>
    908             <p id="rfc.section.2.3.p.6"><span id="rfc.iref.t.1"></span> <span id="rfc.iref.n.1"></span> An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications,
    909                beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original
    910                sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared
    911                annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder,
    912                or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
    913                that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
    914                a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.
    915             </p>
    916             <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection, but translates received requests and forwards
     905               for the sake of security, annotation services, or shared caching. Some proxies are designed to apply transformations to selected
     906               messages or payloads while they are being forwarded, as described in <a href="#message.transformations" title="Transformations">Section&nbsp;5.7.2</a>.
     907            </p>
     908            <p id="rfc.section.2.3.p.6"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is an intermediary that acts as an origin server for the outbound connection, but translates received requests and forwards
    917909               them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services,
    918910               to improve server performance through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.
    919911            </p>
    920             <p id="rfc.section.2.3.p.8">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates
     912            <p id="rfc.section.2.3.p.7">All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates
    921913               with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of
    922914               this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers ought to conform
    923915               to user agent requirements on the gateway's inbound connection.
    924916            </p>
    925             <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
     917            <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.1"></span> A "<dfn>tunnel</dfn>" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party
    926918               to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
    927919               ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
    928920               when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
    929921            </p>
    930             <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     922            <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.2"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
    931923               intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the
    932924               knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems
     
    936928               and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack.
    937929            </p>
    938             <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
     930            <p id="rfc.section.2.3.p.10">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    939931               depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple
    940932               servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
     
    958950</pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "<dfn>cacheable</dfn>" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response
    959951               is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
    960                can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     952               can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in <a href="p6-cache.html#caching.overview" title="Overview of Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    961953            </p>
    962954            <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large
     
    10711063            <div id="rfc.iref.r.5"></div>
    10721064            <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a href="#uri">Uniform Resource Identifiers</a></h2>
    1073             <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
    1074             </p>
    1075             <p id="rfc.section.2.7.p.2">This specification adopts the definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host",
    1076                "path-abempty", "segment", "query", and "fragment" from the URI generic syntax. In addition, we define an "absolute-path"
    1077                rule (that differs from RFC 3986's "path-absolute" in that it allows a leading "//") and a "partial-URI" rule for protocol
    1078                elements that allow a relative URI but not a fragment.
     1065            <p id="rfc.section.2.7.p.1">Uniform Resource Identifiers (URIs) <a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> are used throughout HTTP as the means for identifying resources (<a href="p2-semantics.html#resources" title="Resources">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). URI references are used to target requests, indicate redirects, and define relationships.
     1066            </p>
     1067            <p id="rfc.section.2.7.p.2">The definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment",
     1068               "query", and "fragment" are adopted from the URI generic syntax. An "absolute-path" rule is defined, differing slightly from
     1069               RFC 3986's "path-absolute" in that it allows a leading "//". A "partial-URI" rule is defined for protocol elements that allow
     1070               a relative URI but not a fragment.
    10791071            </p>
    10801072            <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#uri" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#RFC3986" id="rfc.xref.RFC3986.3"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.1">Section 4.1</a>&gt;
     
    11221114               </p>
    11231115               <p id="rfc.section.2.7.1.p.7">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port,
    1124                   and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
     1116                  and sending an HTTP request message (<a href="#http.message" title="Message Format">Section&nbsp;3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section&nbsp;5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.
    11251117               </p>
    11261118               <p id="rfc.section.2.7.1.p.8">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name
     
    12361228               </div>
    12371229               <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1238 </pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1230</pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    12391231               </p>
    12401232               <div id="rfc.iref.r.6"></div>
     
    12481240               </p>
    12491241               <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1250                   it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1242                  it implements <em class="bcp14">SHOULD</em> respond with a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server ought to be prepared to receive URIs of unbounded length, as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>, and <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target is longer than the server wishes to parse (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    12511243               </p>
    12521244               <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.
     
    12611253</pre><p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy
    12621254                  the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined
    1263                   for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
     1255                  for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),
    12641256                  the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry.
    12651257               </p>
     
    12851277                 ; see <a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>
    12861278</pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example,
    1287                the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
     1279               the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.
    12881280            </p>
    12891281            <div id="field.extensibility">
     
    12991291                  of deployed intermediaries.
    13001292               </p>
    1301                <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     1293               <p id="rfc.section.3.2.1.p.4">All defined header fields ought to be registered with IANA in the Message Header Field Registry, as described in <a href="p2-semantics.html#header.field.registry" title="Header Field Registry">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    13021294               </p>
    13031295            </div>
     
    14471439            </p>
    14481440            <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
    1449                status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
     1441               status code (<a href="#status.line" title="Status Line">Section&nbsp;3.1.2</a>). Responses to the HEAD request method (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.), if present, indicate only what their values would have been if the request method had been GET (<a href="p2-semantics.html#GET" title="GET">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to a CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses do not include a message body. All other responses do include a message body, although the body might be of zero
    14501442               length.
    14511443            </p>
    14521444            <div id="header.transfer-encoding">
    1453                <div id="rfc.iref.t.4"></div>
     1445               <div id="rfc.iref.t.3"></div>
    14541446               <div id="rfc.iref.c.6"></div>
    14551447               <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a href="#header.transfer-encoding">Transfer-Encoding</a></h3>
     
    14721464                  forming the message body.
    14731465               </p>
    1474                <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
     1466               <p id="rfc.section.3.3.1.p.6">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the representation, and any recipient along the request/response
    14751467                  chain <em class="bcp14">MAY</em> decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding
    14761468                  changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     
    14801472                  any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
    14811473               </p>
    1482                <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1474               <p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    14831475               </p>
    14841476               <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
     
    14951487                  payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information
    14961488                  necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length
    1497                   indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1489                  indicates the size of the selected representation (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    14981490               </p>
    14991491               <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#header.content-length" class="smpl">Content-Length</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
     
    15061498                  anticipate such a body.
    15071499               </p>
    1508                <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
     1500               <p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
    15091501                  in the payload body of a response if the same request had used the GET method.
    15101502               </p>
     
    15121504                  in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    15131505               </p>
    1514                <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     1506               <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    15151507               </p>
    15161508               <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
     
    16061598            </p>
    16071599            <p id="rfc.section.3.4.p.2">A client that receives an incomplete response message, which can occur when a connection is closed prematurely or when decoding
    1608                a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
     1600               a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    16091601            </p>
    16101602            <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might
     
    17771769         </div>
    17781770         <div id="header.te">
    1779             <div id="rfc.iref.t.5"></div>
     1771            <div id="rfc.iref.t.4"></div>
    17801772            <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#header.te">TE</a></h2>
    17811773            <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response,
     
    18011793            </p>
    18021794            <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation
    1803                fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
     1795               fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
    18041796               a value of 0 means "not acceptable".
    18051797            </p>
     
    18111803         </div>
    18121804         <div id="header.trailer">
    1813             <div id="rfc.iref.t.6"></div>
     1805            <div id="rfc.iref.t.5"></div>
    18141806            <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#header.trailer">Trailer</a></h2>
    18151807            <p id="rfc.section.4.4.p.1">When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in
     
    18281820         </p>
    18291821         <div id="target-resource">
     1822            <div id="rfc.iref.t.6"></div>
    18301823            <div id="rfc.iref.t.7"></div>
    1831             <div id="rfc.iref.t.8"></div>
    18321824            <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#target-resource">Identifying a Target Resource</a></h2>
    18331825            <p id="rfc.section.5.1.p.1">HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases,
     
    18361828            </p>
    18371829            <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
    1838                are defined in <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
     1830               are defined in <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
    18391831               processing (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
    18401832            </p>
     
    18451837               semantics and, if so, where that request is to be directed.
    18461838            </p>
    1847             <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> and the request can be satisfied by it, then the request is usually directed there first.
     1839            <p id="rfc.section.5.2.p.2">If the client has a cache <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> and the request can be satisfied by it, then the request is usually directed there first.
    18481840            </p>
    18491841            <p id="rfc.section.5.2.p.3">If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy
     
    19061898               </p>
    19071899            </div>
    1908             <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
     1900            <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
    19091901            </p>
    19101902            <div id="rfc.figure.u.42"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
     
    19131905               </p>
    19141906            </div>
    1915             <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
     1907            <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
    19161908               the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
    19171909            </p>
     
    20011993            <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
    20021994               messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
    2003                on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
     1995               on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
    20041996            </p>
    20051997            <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final
     
    20682060            </div>
    20692061            <div id="message.transformations">
     2062               <div id="rfc.iref.t.8"></div>
     2063               <div id="rfc.iref.n.1"></div>
    20702064               <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a href="#message.transformations">Transformations</a></h3>
    2071                <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A transforming proxy might, for example,
    2072                   convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational
    2073                   problems might occur when these transformations are applied to payloads intended for critical applications, such as medical
    2074                   imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the
    2075                   payload received is identical to the original.
    2076                </p>
    2077                <p id="rfc.section.5.7.2.p.2">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
    2078                </p>
    2079                <p id="rfc.section.5.7.2.p.3">A proxy <em class="bcp14">MUST NOT</em> modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server,
     2065               <p id="rfc.section.5.7.2.p.1">Some intermediaries include features for transforming messages and their payloads. A proxy might, for example, convert between
     2066                  image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems
     2067                  might occur when these transformations are applied to payloads intended for critical applications, such as medical imaging
     2068                  or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the payload
     2069                  received is identical to the original.
     2070               </p>
     2071               <p id="rfc.section.5.7.2.p.2">An HTTP-to-HTTP proxy is called a "<dfn>transforming proxy</dfn>" if it is designed or configured to modify messages in a semantically meaningful way (i.e., modifications, beyond those required
     2072                  by normal HTTP processing, that change the message in a way that would be significant to the original sender or potentially
     2073                  significant to downstream recipients). For example, a transforming proxy might be acting as a shared annotation server (modifying
     2074                  responses to include references to a local annotation database), a malware filter, a format transcoder, or a privacy filter.
     2075                  Such transformations are presumed to be desired by whichever client (or client organization) selected the proxy.
     2076               </p>
     2077               <p id="rfc.section.5.7.2.p.3">If a proxy receives a request-target with a host name that is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its own domain to the host name it received when forwarding the request. A proxy <em class="bcp14">MUST NOT</em> change the host name if it is a fully qualified domain name.
     2078               </p>
     2079               <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify the "absolute-path" and "query" parts of the received request-target when forwarding it to the next inbound server,
    20802080                  except as noted above to replace an empty path with "/" or "*".
    20812081               </p>
    2082                <p id="rfc.section.5.7.2.p.4">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
     2082               <p id="rfc.section.5.7.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
    20832083                  selected representation. A proxy <em class="bcp14">MAY</em> change the message body through application or removal of a transfer coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    20842084               </p>
    2085                <p id="rfc.section.5.7.2.p.5">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the message payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A transforming proxy <em class="bcp14">MUST NOT</em> modify the payload of a message that contains the no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    2086                </p>
    2087                <p id="rfc.section.5.7.2.p.6">A transforming proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed,
    2088                   the transforming proxy <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one does not already appear in the message
    2089                   (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). If the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response is transformed, the transforming proxy can also inform downstream recipients that a transformation has been applied
    2090                   by changing the response status code to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2085               <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2086               </p>
     2087               <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a
     2088                  payload <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code
     2089                  to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    20912090               </p>
    20922091            </div>
     
    21282127  <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a>
    21292128</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    2130             <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     2129            <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    21312130            </p>
    21322131            <p id="rfc.section.6.1.p.8">The connection options do not always correspond to a header field present in the message, since a connection-specific header
     
    21922191               </p>
    21932192               <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent
    2194                   methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
     2193                  methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
    21952194               </p>
    21962195               <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are
     
    22062205            <div id="pipelining">
    22072206               <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a href="#pipelining">Pipelining</a></h3>
    2208                <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
     2207               <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
    22092208               </p>
    22102209               <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined
     
    22132212                  problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section&nbsp;6.6</a>).
    22142213               </p>
    2215                <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
     2214               <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
    22162215                  the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
    22172216               </p>
     
    23372336            </p>
    23382337            <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e.,
    2339                the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
     2338               the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
    23402339            </p>
    23412340            <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    23422341               the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2343                purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2342               purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    23442343            </p>
    23452344            <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     
    26732672                  <li>Pointer to specification text</li>
    26742673               </ul>
    2675                <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2674               <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    26762675               </p>
    26772676               <p id="rfc.section.8.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this specification.
     
    28822881               that most implementations will choose substantially higher limits.
    28832882            </p>
    2884             <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2883            <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    28852884            </p>
    28862885            <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
     
    36373636            </li>
    36383637            <li><a id="rfc.index.N" href="#rfc.index.N"><b>N</b></a><ul>
    3639                   <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>2.3</b></a></li>
     3638                  <li>non-transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.n.1"><b>5.7.2</b></a></li>
    36403639               </ul>
    36413640            </li>
     
    36473646            </li>
    36483647            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3649                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.4">2.3</a>, <a href="#rfc.xref.Part2.5">2.7</a>, <a href="#rfc.xref.Part2.6">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.1</a>, <a href="#rfc.xref.Part2.9">3.1.2</a>, <a href="#rfc.xref.Part2.10">3.2</a>, <a href="#rfc.xref.Part2.11">3.2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.14">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">3.3.2</a>, <a href="#rfc.xref.Part2.20">4.3</a>, <a href="#rfc.xref.Part2.21">5.1</a>, <a href="#rfc.xref.Part2.22">5.3</a>, <a href="#rfc.xref.Part2.23">5.3</a>, <a href="#rfc.xref.Part2.24">5.6</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">6.7</a>, <a href="#rfc.xref.Part2.32">8.4.1</a>, <a href="#rfc.xref.Part2.33">9.3</a>, <a href="#rfc.xref.Part2.34">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
    3650                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7</a></li>
    3651                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">3.3.2</a></li>
    3652                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.32">8.4.1</a></li>
    3653                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
    3654                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a></li>
    3655                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.3.2</a></li>
    3656                         <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a></li>
    3657                         <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.13">3.3</a></li>
    3658                         <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.18">3.3.2</a></li>
    3659                         <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.1</a>, <a href="#rfc.xref.Part2.19">3.3.2</a>, <a href="#rfc.xref.Part2.22">5.3</a></li>
    3660                         <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.3</a></li>
    3661                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
    3662                         <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">4.3</a></li>
    3663                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">2.7.1</a>, <a href="#rfc.xref.Part2.9">3.1.2</a></li>
    3664                         <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.6</a></li>
    3665                         <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3</a>, <a href="#rfc.xref.Part2.26">5.7.2</a></li>
    3666                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">6.7</a></li>
    3667                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.34">9.3</a></li>
    3668                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.1.1</a>, <a href="#rfc.xref.Part2.33">9.3</a></li>
    3669                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2</a></li>
    3670                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.2.1</a></li>
     3648                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4.3</a>, <a href="#rfc.xref.Part2.20">5.1</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.3</a>, <a href="#rfc.xref.Part2.23">5.6</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">6.3.1</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">8.4.1</a>, <a href="#rfc.xref.Part2.32">9.3</a>, <a href="#rfc.xref.Part2.33">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
     3649                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
     3650                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">3.3.2</a></li>
     3651                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.31">8.4.1</a></li>
     3652                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.7.2</a></li>
     3653                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
     3654                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.3.2</a></li>
     3655                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li>
     3656                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a></li>
     3657                        <li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.17">3.3.2</a></li>
     3658                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.21">5.3</a></li>
     3659                        <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.3</a></li>
     3660                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
     3661                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">4.3</a></li>
     3662                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
     3663                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.6</a></li>
     3664                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.7.2</a></li>
     3665                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.30">6.7</a></li>
     3666                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.33">9.3</a></li>
     3667                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.32">9.3</a></li>
     3668                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
     3669                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
    36713670                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.1</a></li>
    36723671                     </ul>
     
    36773676                  </li>
    36783677                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">1</a>, <a href="#Part5"><b>11.1</b></a></li>
    3679                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.3">2.4</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">5.7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>11.1</b></a><ul>
    3680                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.4</a></li>
    3681                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    3682                         <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>
    3683                         <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.3</a>, <a href="#rfc.xref.Part6.7">5.7.2</a></li>
     3678                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">3.4</a>, <a href="#rfc.xref.Part6.4">5.2</a>, <a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.6">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>11.1</b></a><ul>
     3679                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
     3680                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">3.4</a></li>
     3681                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">5.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
     3682                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.7.2</a></li>
    36843683                     </ul>
    36853684                  </li>
     
    37673766            </li>
    37683767            <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul>
    3769                   <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.1</b></a></li>
    3770                   <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.1</b></a></li>
    3771                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.2</a>, <a href="#rfc.iref.t.5"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">8.1</a></li>
    3772                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.1">8.1</a></li>
    3773                   <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">8.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
    3774                   <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    3775                   <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>
    3776                   <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
     3768                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.6"><b>5.1</b></a></li>
     3769                  <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.1</b></a></li>
     3770                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.2</a>, <a href="#rfc.iref.t.4"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">8.1</a></li>
     3771                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.1">8.1</a></li>
     3772                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.3"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">8.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li>
     3773                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.7.2</b></a></li>
     3774                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.2"><b>2.3</b></a></li>
     3775                  <li>tunnel&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    37773776               </ul>
    37783777            </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2561 r2563  
    303303   these programs perform for a particular connection.  The same program
    304304   might act as a client on some connections and a server on others.
    305    We use the term "<x:dfn>user agent</x:dfn>" to refer to any of the various
     305   The term "<x:dfn>user agent</x:dfn>" refers to any of the various
    306306   client programs that initiate a request, including (but not limited to)
    307    browsers, spiders (web-based robots), command-line tools, native
    308    applications, and mobile apps.  The term "<x:dfn>origin server</x:dfn>" is
    309    used to refer to the program that can originate authoritative responses to
    310    a request. For general requirements, we use the terms
    311    "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" to refer to any
    312    component that sends or receives, respectively, a given message.
     307   browsers, spiders (web-based robots), command-line tools, custom
     308   applications, and mobile apps.
     309   The term "<x:dfn>origin server</x:dfn>" refers to the program that can
     310   originate authoritative responses for a given target resource.
     311   The terms "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" refer to
     312   any implementation that sends or receives a given message, respectively.
    313313</t>
    314314<t>
     
    416416</t>
    417417<t>
    418    The implementation diversity of HTTP means that we cannot assume the
    419    user agent can make interactive suggestions to a user or provide adequate
    420    warning for security or privacy options. In the few cases where this
     418   The implementation diversity of HTTP means that not all user agents can
     419   make interactive suggestions to their user or provide adequate warning for
     420   security or privacy concerns. In the few cases where this
    421421   specification requires reporting of errors to the user, it is acceptable
    422422   for such reporting to only be observable in an error console or log file.
     
    461461<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
    462462<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    463    We use the terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>"
    464    to describe various requirements in relation to the directional flow of a
    465    message: all messages flow from upstream to downstream.
    466    Likewise, we use the terms inbound and outbound to refer to
    467    directions in relation to the request path:
     463   The terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>" are
     464   used to describe directional requirements in relation to the message flow:
     465   all messages flow from upstream to downstream.
     466   The terms inbound and outbound are used to describe directional
     467   requirements in relation to the request route:
    468468   "<x:dfn>inbound</x:dfn>" means toward the origin server and
    469469   "<x:dfn>outbound</x:dfn>" means toward the user agent.
     
    478478   application-level protocols. Proxies are often used to group an
    479479   organization's HTTP requests through a common intermediary for the
    480    sake of security, annotation services, or shared caching.
    481 </t>
    482 <t>
    483 <iref primary="true" item="transforming proxy"/>
    484 <iref primary="true" item="non-transforming proxy"/>
    485    An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>" if it is designed
    486    or configured to modify request or response messages in a semantically
    487    meaningful way (i.e., modifications, beyond those required by normal
    488    HTTP processing, that change the message in a way that would be
    489    significant to the original sender or potentially significant to
    490    downstream recipients).  For example, a transforming proxy might be
    491    acting as a shared annotation server (modifying responses to include
    492    references to a local annotation database), a malware filter, a
    493    format transcoder, or an intranet-to-Internet privacy filter.  Such
    494    transformations are presumed to be desired by the client (or client
    495    organization) that selected the proxy and are beyond the scope of
    496    this specification.  However, when a proxy is not intended to transform
    497    a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target
    498    requirements that preserve HTTP message semantics. See &status-203; and
    499    &header-warning; for status and warning codes related to transformations.
     480   sake of security, annotation services, or shared caching. Some proxies
     481   are designed to apply transformations to selected messages or payloads
     482   while they are being forwarded, as described in
     483   <xref target="message.transformations"/>.
    500484</t>
    501485<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
     
    828812  <x:anchor-alias value="partial-URI"/>
    829813<t>
    830    This specification adopts the definitions of "URI-reference",
     814   The definitions of "URI-reference",
    831815   "absolute-URI", "relative-part", "authority", "port", "host",
    832    "path-abempty", "segment", "query", and "fragment" from the
     816   "path-abempty", "segment", "query", and "fragment" are adopted from the
    833817   URI generic syntax.
    834    In addition, we define an "absolute-path" rule (that differs from
    835    RFC 3986's "path-absolute" in that it allows a leading "//")
    836    and a "partial-URI" rule for protocol elements
     818   An "absolute-path" rule is defined, differing slightly from
     819   RFC 3986's "path-absolute" in that it allows a leading "//".
     820   A "partial-URI" rule is defined for protocol elements
    837821   that allow a relative URI but not a fragment.
    838822</t>
     
    27472731
    27482732<section title="Transformations" anchor="message.transformations">
     2733   <iref primary="true" item="transforming proxy"/>
     2734   <iref primary="true" item="non-transforming proxy"/>
    27492735<t>
    27502736   Some intermediaries include features for transforming messages and their
    2751    payloads.  A transforming proxy might, for example, convert between image
    2752    formats in order to save cache space or to reduce the amount of traffic on
    2753    a slow link. However, operational problems might occur when these
    2754    transformations are applied to payloads intended for critical applications,
    2755    such as medical imaging or scientific data analysis, particularly when
    2756    integrity checks or digital signatures are used to ensure that the payload
    2757    received is identical to the original.
     2737   payloads. A proxy might, for example, convert between image formats in
     2738   order to save cache space or to reduce the amount of traffic on a slow
     2739   link. However, operational problems might occur when these transformations
     2740   are applied to payloads intended for critical applications, such as medical
     2741   imaging or scientific data analysis, particularly when integrity checks or
     2742   digital signatures are used to ensure that the payload received is
     2743   identical to the original.
     2744</t>
     2745<t>
     2746   An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>"
     2747   if it is designed or configured to modify messages in a semantically
     2748   meaningful way (i.e., modifications, beyond those required by normal
     2749   HTTP processing, that change the message in a way that would be
     2750   significant to the original sender or potentially significant to
     2751   downstream recipients).  For example, a transforming proxy might be
     2752   acting as a shared annotation server (modifying responses to include
     2753   references to a local annotation database), a malware filter, a
     2754   format transcoder, or a privacy filter. Such transformations are presumed
     2755   to be desired by whichever client (or client organization) selected the
     2756   proxy.
    27582757</t>
    27592758<t>
     
    27752774</t>
    27762775<t>
    2777    A non-transforming proxy &MUST-NOT; modify the message payload (&payload;).
    2778    A transforming proxy &MUST-NOT; modify the payload of a message that
    2779    contains the no-transform cache-control directive (&header-cache-control;).
    2780 </t>
    2781 <t>
    2782    A transforming proxy &MAY; transform the payload of a message
    2783    that does not contain the no-transform cache-control directive;
    2784    if the payload is transformed, the transforming proxy &MUST; add a
     2776   A proxy &MUST-NOT; modify the payload (&payload;) of a message that
     2777   contains a no-transform cache-control directive (&header-cache-control;).
     2778</t>
     2779<t>
     2780   A proxy &MAY; transform the payload of a message
     2781   that does not contain a no-transform cache-control directive.
     2782   A proxy that transforms a payload &MUST; add a
    27852783   Warning header field with the warn-code of 214 ("Transformation Applied")
    2786    if one does not already appear in the message (see &header-warning;).
    2787    If the payload of a <x:ref>200 (OK)</x:ref> response is transformed, the
    2788    transforming proxy can also inform downstream recipients that a
    2789    transformation has been applied by changing the response status code to
     2784   if one is not already in the message (see &header-warning;).
     2785   A proxy that transforms the payload of a <x:ref>200 (OK)</x:ref> response
     2786   can further inform downstream recipients that a transformation has been
     2787   applied by changing the response status code to
    27902788   <x:ref>203 (Non-Authoritative Information)</x:ref> (&status-203;).
    27912789</t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2562 r2563  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 22, 2014";
     450       content: "Expires July 23, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 18, 2014</td>
     523               <td class="right">January 19, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 22, 2014</td>
     526               <td class="left">Expires: July 23, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 22, 2014.</p>
     555         <p>This Internet-Draft will expire on July 23, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    848848         <div id="rfc.iref.s.1"></div>
    849849         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#representations">Representations</a></h1>
    850          <p id="rfc.section.3.p.1">If we consider that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through
     850         <p id="rfc.section.3.p.1">Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through
    851851            which one can observe and act upon such a thing only through the communication of messages to some independent actor on the
    852             other side, then we need an abstraction to represent ("take the place of") the current or desired state of that thing in our
    853             communications. We call that abstraction a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.
     852            other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our
     853            communications. That abstraction is called a representation <a href="#REST" id="rfc.xref.REST.1"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>.
    854854         </p>
    855855         <p id="rfc.section.3.p.2">For the purposes of HTTP, a "<dfn>representation</dfn>" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be
     
    859859         <p id="rfc.section.3.p.3">An origin server might be provided with, or capable of generating, multiple representations that are each intended to reflect
    860860            the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to
    861             a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. We refer to that one representation as the "<dfn>selected representation</dfn>" and use its particular data and metadata for evaluating conditional requests <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
     861            a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
    862862         </p>
    863863         <div id="representation.metadata">
     
    42134213            <p id="rfc.section.9.6.p.2">There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable
    42144214               fingerprinting. The <a href="#header.from" class="smpl">From</a> header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by
    4215                the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so we can assume that fingerprinting
    4216                concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
     4215               the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns
     4216               only apply to situations where cookies are disabled or restricted by the user agent's configuration.
    42174217            </p>
    42184218            <p id="rfc.section.9.6.p.3">The <a href="#header.user-agent" class="smpl">User-Agent</a> header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics,
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2562 r2563  
    298298   <x:anchor-alias value="selected representation"/>
    299299<t>
    300    If we consider that a resource could be anything, and that the uniform
    301    interface provided by HTTP is similar to a window through which one
    302    can observe and act upon such a thing only through the communication of
    303    messages to some independent actor on the other side, then we need an
    304    abstraction to represent ("take the place of") the current or desired state
    305    of that thing in our communications. We call that abstraction a
     300   Considering that a resource could be anything, and that the uniform
     301   interface provided by HTTP is similar to a window through which one can
     302   observe and act upon such a thing only through the communication of
     303   messages to some independent actor on the other side, an abstraction is
     304   needed to represent ("take the place of") the current or desired state of
     305   that thing in our communications. That abstraction is called a
    306306   representation <xref target="REST"/>.
    307307</t>
     
    319319   the origin server to select one of those representations as most applicable
    320320   to a given request, usually based on <x:ref>content negotiation</x:ref>.
    321    We refer to that one representation as the
    322    "<x:dfn>selected representation</x:dfn>" and use its particular data and
    323    metadata for evaluating conditional requests <xref target="Part4"/> and
     321   This "<x:dfn>selected representation</x:dfn>" is used to provide the data
     322   and metadata for evaluating conditional requests <xref target="Part4"/> and
    324323   constructing the payload for <x:ref>200 (OK)</x:ref> and
    325324   <x:ref>304 (Not Modified)</x:ref> responses to GET (<xref target="GET"/>).
     
    50435042   expected that From will only be sent when self-identification is desired by
    50445043   the user. Likewise, Cookie header fields are deliberately designed to
    5045    enable re-identification, so we can assume that fingerprinting concerns
    5046    only apply to situations where cookies are disabled or restricted by the
    5047    user agent's configuration.
     5044   enable re-identification, so fingerprinting concerns only apply to
     5045   situations where cookies are disabled or restricted by the user agent's
     5046   configuration.
    50485047</t>
    50495048<t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2554 r2563  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 21, 2014";
     450       content: "Expires July 23, 2014";
    451451  }
    452452  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     493      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
     
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 21, 2014</td>
    520                <td class="right">January 17, 2014</td>
     519               <td class="left">Expires: July 23, 2014</td>
     520               <td class="right">January 19, 2014</td>
    521521            </tr>
    522522         </tbody>
     
    546546            in progress”.
    547547         </p>
    548          <p>This Internet-Draft will expire on July 21, 2014.</p>
     548         <p>This Internet-Draft will expire on July 23, 2014.</p>
    549549      </div>
    550550      <div id="rfc.copyrightnotice">
     
    930930         <div id="when.to.use.entity.tags.and.last-modified.dates">
    931931            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2>
    932             <p id="rfc.section.2.4.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types
    933                ought to be used, and for what purposes.
    934             </p>
    935             <p id="rfc.section.2.4.p.2">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server:
     932            <p id="rfc.section.2.4.p.1">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server:
    936933            </p>
    937934            <ul>
     
    944941               </li>
    945942            </ul>
    946             <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value in successful responses to a retrieval request.
    947             </p>
    948             <p id="rfc.section.2.4.p.4">A client: </p>
     943            <p id="rfc.section.2.4.p.2">In other words, the preferred behavior for an origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value in successful responses to a retrieval request.
     944            </p>
     945            <p id="rfc.section.2.4.p.3">A client: </p>
    949946            <ul>
    950947               <li><em class="bcp14">MUST</em> send that entity-tag in any cache validation request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2554 r2563  
    602602<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
    603603<t>
    604    We adopt a set of rules and recommendations for origin servers,
    605    clients, and caches regarding when various validator types ought to
    606    be used, and for what purposes.
    607 </t>
    608 <t>
    609604   In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
    610605  <list style="symbols">
  • draft-ietf-httpbis/latest/p5-range.html

    r2560 r2563  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 22, 2014";
     450       content: "Expires July 23, 2014";
    451451  }
    452452  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
     493      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
     
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 22, 2014</td>
     519               <td class="left">Expires: July 23, 2014</td>
    520520               <td class="right">J. Reschke, Editor</td>
    521521            </tr>
     
    526526            <tr>
    527527               <td class="left"></td>
    528                <td class="right">January 18, 2014</td>
     528               <td class="right">January 19, 2014</td>
    529529            </tr>
    530530         </tbody>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 22, 2014.</p>
     555         <p>This Internet-Draft will expire on July 23, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    673673            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#byte.ranges">Byte Ranges</a></h2>
    674674            <p id="rfc.section.2.1.p.1">Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for
    675                any representation transferable over HTTP (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). We define the "bytes" range unit for expressing subranges of the data's octet sequence.
     675               any representation transferable over HTTP (<a href="p2-semantics.html#representations" title="Representations">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The "bytes" range unit is defined for expressing subranges of the data's octet sequence.
    676676            </p>
    677677            <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#byte.ranges" class="smpl">bytes-unit</a>       = "bytes"
  • draft-ietf-httpbis/latest/p5-range.xml

    r2560 r2563  
    208208   Since representation data is transferred in payloads as a sequence of
    209209   octets, a byte range is a meaningful substructure for any representation
    210    transferable over HTTP (&representation;). We define the "bytes" range
    211    unit for expressing subranges of the data's octet sequence.
     210   transferable over HTTP (&representation;). The "bytes" range unit is
     211   defined for expressing subranges of the data's octet sequence.
    212212</t>
    213213<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="bytes-unit"/>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2554 r2563  
    451451  }
    452452  @bottom-center {
    453        content: "Expires July 21, 2014";
     453       content: "Expires July 23, 2014";
    454454  }
    455455  @bottom-right {
     
    495495      <meta name="dct.creator" content="Reschke, J. F.">
    496496      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    497       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     497      <meta name="dct.issued" scheme="ISO8601" content="2014-01-19">
    498498      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    499499      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    521521            </tr>
    522522            <tr>
    523                <td class="left">Expires: July 21, 2014</td>
     523               <td class="left">Expires: July 23, 2014</td>
    524524               <td class="right">J. Reschke, Editor</td>
    525525            </tr>
     
    530530            <tr>
    531531               <td class="left"></td>
    532                <td class="right">January 17, 2014</td>
     532               <td class="right">January 19, 2014</td>
    533533            </tr>
    534534         </tbody>
     
    557557            in progress”.
    558558         </p>
    559          <p>This Internet-Draft will expire on July 21, 2014.</p>
     559         <p>This Internet-Draft will expire on July 23, 2014.</p>
    560560      </div>
    561561      <div id="rfc.copyrightnotice">
     
    746746         <div id="rfc.iref.c.3"></div>
    747747         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#caching.overview">Overview of Cache Operation</a></h1>
    748          <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
    749             no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache from
    750             either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches always
    751             store and reuse particular responses.
     748         <p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, it can be assumed that reusing a cached response is desirable and that such reuse is the default behavior
     749            when no requirement or local configuration prevents it. Therefore, HTTP cache requirements are focused on preventing a cache
     750            from either storing a non-reusable response or reusing a stored response inappropriately, rather than mandating that caches
     751            always store and reuse particular responses.
    752752         </p>
    753753         <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
     
    14581458               <h3 id="rfc.section.5.2.3"><a href="#rfc.section.5.2.3">5.2.3</a>&nbsp;<a href="#cache.control.extensions">Cache Control Extensions</a></h3>
    14591459               <p id="rfc.section.5.2.3.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional
    1460                   value.
     1460                  value. A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives.
    14611461               </p>
    14621462               <p id="rfc.section.5.2.3.p.2">Informational extensions (those that do not require a change in cache behavior) can be added without changing the semantics
    1463                   of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives.
    1464                </p>
    1465                <p id="rfc.section.5.2.3.p.3">Both the new directive and the standard directive are supplied, such that applications that do not understand the new directive
    1466                   will default to the behavior specified by the standard directive, and those that understand the new directive will recognize
    1467                   it as modifying the requirements associated with the standard directive. In this way, extensions to the cache-control directives
    1468                   can be made without requiring changes to the base protocol.
    1469                </p>
    1470                <p id="rfc.section.5.2.3.p.4">This extension mechanism depends on an HTTP cache obeying all of the cache-control directives defined for its native HTTP-version,
    1471                   obeying certain extensions, and ignoring all directives that it does not understand.
    1472                </p>
    1473                <p id="rfc.section.5.2.3.p.5">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive.
    1474                   We define this new directive to mean that, in addition to any private cache, any cache that is shared only by members of the
    1475                   community named within its value is allowed to cache the response. An origin server wishing to allow the UCI community to
    1476                   use an otherwise private response in their shared cache(s) could do so by including
     1463                  of other directives.
     1464               </p>
     1465               <p id="rfc.section.5.2.3.p.3">Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive
     1466                  and the old directive are supplied, such that applications that do not understand the new directive will default to the behavior
     1467                  specified by the old directive, and those that understand the new directive will recognize it as modifying the requirements
     1468                  associated with the old directive. In this way, extensions to the existing cache-control directives can be made without breaking
     1469                  deployed caches.
     1470               </p>
     1471               <p id="rfc.section.5.2.3.p.4">For example, consider a hypothetical new response directive called "community" that acts as a modifier to the private directive:
     1472                  in addition to private caches, any cache that is shared only by members of the named community is allowed to cache the response.
     1473                  An origin server wishing to allow the UCI community to use an otherwise private response in their shared cache(s) could do
     1474                  so by including
    14771475               </p>
    14781476               <div id="rfc.figure.u.8"></div><pre class="text">  Cache-Control: private, community="UCI"
    1479 </pre><p id="rfc.section.5.2.3.p.7">A cache seeing this header field will act correctly even if the cache does not understand the community cache-extension, since
    1480                   it will also see and understand the private directive and thus default to the safe behavior.
    1481                </p>
    1482                <p id="rfc.section.5.2.3.p.8">A cache <em class="bcp14">MUST</em> ignore unrecognized cache directives; it is assumed that any cache directive likely to be unrecognized by an HTTP/1.1 cache
    1483                   will be combined with standard directives (or the response's default cacheability) such that the cache behavior will remain
    1484                   minimally correct even if the cache does not understand the extension(s).
     1477</pre><p id="rfc.section.5.2.3.p.6">A cache that recognizes such a community cache-extension could broaden its behavior in accordance with that extension. A cache
     1478                  that does not recognize the community cache-extension would ignore it and adhere to the private directive.
    14851479               </p>
    14861480            </div>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2554 r2563  
    251251   (&semantics;) while eliminating the transfer of information already held
    252252   in the cache.  Although caching is an entirely &OPTIONAL; feature of HTTP,
    253    we assume that reusing the cached response is desirable and that such
     253   it can be assumed that reusing a cached response is desirable and that such
    254254   reuse is the default behavior when no requirement or local
    255255   configuration prevents it.  Therefore, HTTP cache requirements are focused
     
    15571557   The Cache-Control header field can be extended through the use of one or
    15581558   more cache-extension tokens, each with an optional value.
     1559   A cache &MUST; ignore unrecognized cache directives.
    15591560</t>
    15601561<t>
    15611562   Informational extensions (those that do not require a change in cache
    15621563   behavior) can be added without changing the semantics of other directives.
     1564</t>
     1565<t>   
    15631566   Behavioral extensions are designed to work by acting as modifiers to the
    15641567   existing base of cache directives.
    1565 </t>
    1566 <t>   
    1567    Both the new directive and the standard directive are supplied, such that
     1568   Both the new directive and the old directive are supplied, such that
    15681569   applications that do not understand the new directive will default to the
    1569    behavior specified by the standard directive, and those that understand the
     1570   behavior specified by the old directive, and those that understand the
    15701571   new directive will recognize it as modifying the requirements associated
    1571    with the standard directive. In this way, extensions to the cache-control
    1572    directives can be made without requiring changes to the base protocol.
    1573 </t>
    1574 <t>
    1575    This extension mechanism depends on an HTTP cache obeying all of the
    1576    cache-control directives defined for its native HTTP-version, obeying
    1577    certain extensions, and ignoring all directives that it does not
    1578    understand.
     1572   with the old directive. In this way, extensions to the existing
     1573   cache-control directives can be made without breaking deployed caches.
    15791574</t>
    15801575<t>
    15811576   For example, consider a hypothetical new response directive called
    1582    "community" that acts as a modifier to the private directive. We define
    1583    this new directive to mean that, in addition to any private cache, any
    1584    cache that is shared only by members of the community named within its
    1585    value is allowed to cache the response. An origin server wishing to allow
    1586    the UCI community to use an otherwise private response in their shared
    1587    cache(s) could do so by including
     1577   "community" that acts as a modifier to the private directive: in addition
     1578   to private caches, any cache that is shared only by members of the named
     1579   community is allowed to cache the response. An origin server wishing to
     1580   allow the UCI community to use an otherwise private response in their
     1581   shared cache(s) could do so by including
    15881582</t>
    15891583<figure><artwork type="example">
     
    15911585</artwork></figure>
    15921586<t>
    1593    A cache seeing this header field will act correctly even if the cache does
    1594    not understand the community cache-extension, since it will also see and
    1595    understand the private directive and thus default to the safe behavior.
    1596 </t>
    1597 <t>
    1598    A cache &MUST; ignore unrecognized cache directives; it is assumed that any
    1599    cache directive likely to be unrecognized by an HTTP/1.1 cache will be
    1600    combined with standard directives (or the response's default cacheability)
    1601    such that the cache behavior will remain minimally correct even if the
    1602    cache does not understand the extension(s).
     1587   A cache that recognizes such a community cache-extension could broaden its
     1588   behavior in accordance with that extension.  A cache that does not
     1589   recognize the community cache-extension would ignore it and adhere to the
     1590   private directive.
    16031591</t>
    16041592</section>
Note: See TracChangeset for help on using the changeset viewer.