Ignore:
Timestamp:
28/03/11 15:34:32 (11 years ago)
Author:
fielding@…
Message:

editorial: use explicit extended mark-up to emphasize definitions.

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

Legend:

Unmodified
Added
Removed

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

    r1215 r1227  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 28, 2011";
     361       content: "Expires September 29, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-03-27">
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-03-28">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: September 28, 2011</td>
     444               <td class="left">Expires: September 29, 2011</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">March 27, 2011</td>
     497               <td class="right">March 28, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on September 28, 2011.</p>
     525      <p>This Internet-Draft will expire on September 29, 2011.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    872872      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="operation" href="#operation">Client/Server Messaging</a></h2>
    873873      <p id="rfc.section.2.1.p.1">HTTP is a stateless request/response protocol that operates by exchanging messages across a reliable transport or session-layer
    874          connection. An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more
    875          HTTP requests. An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
     874         "<dfn>connection</dfn>". An HTTP "<dfn>client</dfn>" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests. An HTTP "<dfn>server</dfn>" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
    876875      </p>
    877876      <div id="rfc.iref.u.1"></div>
    … …  
    879878      <div id="rfc.iref.b.1"></div>
    880879      <div id="rfc.iref.s.2"></div>
     880      <div id="rfc.iref.s.3"></div>
     881      <div id="rfc.iref.r.1"></div>
    881882      <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
    882          same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the
    883          program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
    884          to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
    885          "sender" to refer to whichever component sent a given message and the term "recipient" to refer to any component that receives
    886          the message.
     883         same program might act as a client on some connections and a server on others. We use the term "<dfn>user agent</dfn>" to refer to the program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the
     884         term "<dfn>origin server</dfn>" to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
     885         "<dfn>sender</dfn>" to refer to whichever component sent a given message and the term "<dfn>recipient</dfn>" to refer to any component that receives the message.
    887886      </p>
    888887      <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
    … …  
    894893                                &lt;   response
    895894</pre><div id="rfc.iref.m.1"></div>
    896       <div id="rfc.iref.r.1"></div>
    897895      <div id="rfc.iref.r.2"></div>
    898       <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a request message (<a href="#request" title="Request">Section&nbsp;4</a>), beginning with a method, URI, and protocol version, followed by MIME-like header fields containing request modifiers, client
     896      <div id="rfc.iref.r.3"></div>
     897      <p id="rfc.section.2.1.p.5">A client sends an HTTP request to the server in the form of a <dfn>request</dfn>  <dfn>message</dfn> (<a href="#request" title="Request">Section&nbsp;4</a>), beginning with a method, URI, and protocol version, followed by MIME-like header fields containing request modifiers, client
    899898         information, and payload metadata, an empty line to indicate the end of the header section, and finally the payload body (if
    900899         any).
    901900      </p>
    902       <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP response message (<a href="#response" title="Response">Section&nbsp;5</a>), beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase, followed
     901      <p id="rfc.section.2.1.p.6">A server responds to the client's request by sending an HTTP <dfn>response</dfn>  <dfn>message</dfn> (<a href="#response" title="Response">Section&nbsp;5</a>), beginning with a status line that includes the protocol version, a success or error code, and textual reason phrase, followed
    903902         by MIME-like header fields containing server information, resource metadata, and payload metadata, an empty line to indicate
    904903         the end of the header section, and finally the payload body (if any).
    … …  
    937936      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
    938937      <p id="rfc.section.2.3.p.1">HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of
    939          HTTP intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy,
    940          gateway, or tunnel, switching behavior based on the nature of each request.
     938         HTTP <dfn>intermediary</dfn>: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel,
     939         switching behavior based on the nature of each request.
    941940      </p>
    942941      <div id="rfc.figure.u.15"></div><pre class="drawing">         &gt;             &gt;             &gt;             &gt;
    … …  
    950949         at the same time that it is handling A's request.
    951950      </p>
    952       <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 "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
    953          all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions
    954          in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent.
    955       </p>
    956       <p id="rfc.section.2.3.p.5"><span id="rfc.iref.p.1"></span> A "proxy" is a message forwarding agent that is selected by the client, usually via local configuration rules, to receive
    957          requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface.
    958          Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation
    959          to and from entirely different application-layer protocols. Proxies are often used to group an organization's HTTP requests
    960          through a common intermediary for the sake of security, annotation services, or shared caching.
    961       </p>
    962       <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 "transforming proxy" if it is designed or configured to modify request or response messages
    963          in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message
    964          in a way that would be significant to the original sender or potentially significant to downstream recipients). For example,
    965          a transforming proxy might be acting as a shared annotation server (modifying responses to include references to a local annotation
    966          database), a malware filter, a format transcoder, or an intranet-to-Internet privacy filter. Such transformations are presumed
    967          to be desired by the client (or client organization) that selected the proxy and are beyond the scope of this specification.
    968          However, when a proxy is not intended to transform a given message, we use the term "non-transforming proxy" to target requirements
    969          that preserve HTTP message semantics.
    970       </p>
    971       <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span>  <span id="rfc.iref.a.1"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
    972          the received requests to the underlying server's protocol. Gateways are often used to encapsulate legacy or untrusted information
    973          services, to improve server performance through "accelerator" caching, and to enable partitioning or load-balancing of HTTP
    974          services across multiple machines.
     951      <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.
     952         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.
     953      </p>
     954      <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
     955         for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations
     956         are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely
     957         different application-layer protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary
     958         for the sake of security, annotation services, or shared caching.
     959      </p>
     960      <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,
     961         beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original
     962         sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared
     963         annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder,
     964         or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization)
     965         that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform
     966         a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics.
     967      </p>
     968      <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.4"></span>  <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying
     969         server's protocol. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance
     970         through "<dfn>accelerator</dfn>" caching, and to enable partitioning or load-balancing of HTTP services across multiple machines.
    975971      </p>
    976972      <p id="rfc.section.2.3.p.8">A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements
    … …  
    979975         However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers <em class="bcp14">MUST</em> comply with HTTP user agent requirements on the gateway's inbound connection and <em class="bcp14">MUST</em> implement the Connection (<a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;9.1</a>) and Via (<a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>) header fields for both connections.
    980976      </p>
    981       <p id="rfc.section.2.3.p.9"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered
    982          a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist
    983          when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary,
    984          such as when transport-layer security is used to establish private communication through a shared firewall proxy.
     977      <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
     978         to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both
     979         ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as
     980         when transport-layer security is used to establish private communication through a shared firewall proxy.
    985981      </p>
    986982      <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> In addition, there may exist network intermediaries that are not considered part of the HTTP communication but nevertheless
    987983         act as filters or redirecting agents (usually violating HTTP semantics, causing security problems, and otherwise making a
    988          mess of things). Such a network intermediary, often referred to as an "interception proxy" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "transparent proxy" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "captive portal", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary
    989          redirects outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception
    990          proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing
    991          use of non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable
     984         mess of things). Such a network intermediary, often referred to as an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a>, "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a>, or "<dfn>captive portal</dfn>", differs from an HTTP proxy because it has not been selected by the client. Instead, the network intermediary redirects
     985         outgoing TCP port 80 packets (and occasionally other common port traffic) to an internal HTTP server. Interception proxies
     986         are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of
     987         non-local Internet services, and within corporate firewalls to enforce network usage policies. They are indistinguishable
    992988         from a man-in-the-middle attack.
    993989      </p>
    994990      <div id="rfc.iref.c.4"></div>
    995991      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="caches" href="#caches">Caches</a></h2>
    996       <p id="rfc.section.2.4.p.1">A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and
    997          deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future,
    998          equivalent requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
     992      <p id="rfc.section.2.4.p.1">A "<dfn>cache</dfn>" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion.
     993         A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
     994         requests. Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server while it is acting as a tunnel.
    999995      </p>
    1000996      <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
    … …  
    10051001       UA =========== A =========== B - - - - - - C - - - - - - O
    10061002                  &lt;             &lt;
    1007 </pre><p id="rfc.section.2.4.p.4"><span id="rfc.iref.c.5"></span> A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    1008          Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when
    1009          that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are
    1010          defined in <a href="p6-cache.html#caching.overview" title="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1003</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
     1004         is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response
     1005         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="Cache Operation">Section 2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    10111006      </p>
    10121007      <p id="rfc.section.2.4.p.5">There are a wide variety of architectures and configurations of caches and proxies deployed across the World Wide Web and
    … …  
    10741069         for the changes introduced between <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> and <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, and this revision is specifically avoiding any such changes to the protocol.
    10751070      </p>
    1076       <div id="rfc.iref.r.4"></div>
     1071      <div id="rfc.iref.r.5"></div>
    10771072      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    10781073      <p id="rfc.section.2.6.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. URI references are used to target requests, indicate redirects,
    … …  
    38453840            </li>
    38463841            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    3847                   <li>request&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>2.1</b></a></li>
    3848                   <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.6</b></a></li>
    3849                   <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li>
    3850                   <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.3</b></a></li>
     3842                  <li>recipient&nbsp;&nbsp;<a href="#rfc.iref.r.1"><b>2.1</b></a></li>
     3843                  <li>request&nbsp;&nbsp;<a href="#rfc.iref.r.2"><b>2.1</b></a></li>
     3844                  <li>resource&nbsp;&nbsp;<a href="#rfc.iref.r.5"><b>2.6</b></a></li>
     3845                  <li>response&nbsp;&nbsp;<a href="#rfc.iref.r.3"><b>2.1</b></a></li>
     3846                  <li>reverse proxy&nbsp;&nbsp;<a href="#rfc.iref.r.4"><b>2.3</b></a></li>
    38513847                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>13.2</b></a><ul>
    38523848                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">6.1</a></li>
    … …  
    39133909            </li>
    39143910            <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
     3911                  <li>sender&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>2.1</b></a></li>
    39153912                  <li>server&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>2.1</b></a></li>
    39163913                  <li><em>Spe</em>&nbsp;&nbsp;<a href="#rfc.xref.Spe.1">7.1.1</a>, <a href="#Spe"><b>13.2</b></a></li>

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

    r1214 r1227  
    532532<t>
    533533   HTTP is a stateless request/response protocol that operates by exchanging
    534    messages across a reliable transport or session-layer connection. An HTTP
    535    "client" is a program that establishes a connection to a server for the
    536    purpose of sending one or more HTTP requests.  An HTTP "server" is a
     534   messages across a reliable transport or session-layer
     535   "<x:dfn>connection</x:dfn>". An HTTP "<x:dfn>client</x:dfn>" is a
     536   program that establishes a connection to a server for the purpose of
     537   sending one or more HTTP requests.  An HTTP "<x:dfn>server</x:dfn>" is a
    537538   program that accepts connections in order to service HTTP requests by
    538539   sending HTTP responses.
    … …  
    542543<iref primary="true" item="browser"/>
    543544<iref primary="true" item="spider"/>
     545<iref primary="true" item="sender"/>
     546<iref primary="true" item="recipient"/>
    544547<t>
    545548   Note that the terms client and server refer only to the roles that
    546549   these programs perform for a particular connection.  The same program
    547550   might act as a client on some connections and a server on others.  We use
    548    the term "user agent" to refer to the program that initiates a request,
     551   the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request,
    549552   such as a WWW browser, editor, or spider (web-traversing robot), and
    550    the term "origin server" to refer to the program that can originate
     553   the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate
    551554   authoritative responses to a request.  For general requirements, we use
    552    the term "sender" to refer to whichever component sent a given message
    553    and the term "recipient" to refer to any component that receives the
     555   the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message
     556   and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the
    554557   message.
    555558</t>
    … …  
    569572<iref primary="true" item="response"/>
    570573<t>
    571    A client sends an HTTP request to the server in the form of a request
    572    message (<xref target="request"/>), beginning with a method, URI, and
     574   A client sends an HTTP request to the server in the form of a <x:dfn>request</x:dfn>
     575   <x:dfn>message</x:dfn> (<xref target="request"/>), beginning with a method, URI, and
    573576   protocol version, followed by MIME-like header fields containing
    574577   request modifiers, client information, and payload metadata, an empty
    … …  
    577580</t>
    578581<t>
    579    A server responds to the client's request by sending an HTTP response
    580    message (<xref target="response"/>), beginning with a status line that
     582   A server responds to the client's request by sending an HTTP <x:dfn>response</x:dfn>
     583   <x:dfn>message</x:dfn> (<xref target="response"/>), beginning with a status line that
    581584   includes the protocol version, a success or error code, and textual
    582585   reason phrase, followed by MIME-like header fields containing server
    … …  
    643646   HTTP enables the use of intermediaries to satisfy requests through
    644647   a chain of connections.  There are three common forms of HTTP
    645    intermediary: proxy, gateway, and tunnel.  In some cases,
     648   <x:dfn>intermediary</x:dfn>: proxy, gateway, and tunnel.  In some cases,
    646649   a single intermediary might act as an origin server, proxy, gateway,
    647650   or tunnel, switching behavior based on the nature of each request.
    … …  
    668671<iref primary="true" item="upstream"/><iref primary="true" item="downstream"/>
    669672<iref primary="true" item="inbound"/><iref primary="true" item="outbound"/>
    670    We use the terms "upstream" and "downstream" to describe various
    671    requirements in relation to the directional flow of a message:
    672    all messages flow from upstream to downstream.
    673    Likewise, we use the terms "inbound" and "outbound" to refer to
    674    directions in relation to the request path: "inbound" means toward
    675    the origin server and "outbound" means toward the user agent.
     673   We use the terms "<x:dfn>upstream</x:dfn>" and "<x:dfn>downstream</x:dfn>"
     674   to describe various requirements in relation to the directional flow of a
     675   message: all messages flow from upstream to downstream.
     676   Likewise, we use the terms inbound and outbound to refer to
     677   directions in relation to the request path:
     678   "<x:dfn>inbound</x:dfn>" means toward the origin server and
     679   "<x:dfn>outbound</x:dfn>" means toward the user agent.
    676680</t>
    677681<t><iref primary="true" item="proxy"/>
    678    A "proxy" is a message forwarding agent that is selected by the
     682   A "<x:dfn>proxy</x:dfn>" is a message forwarding agent that is selected by the
    679683   client, usually via local configuration rules, to receive requests
    680684   for some type(s) of absolute URI and attempt to satisfy those
    … …  
    689693<iref primary="true" item="transforming proxy"/>
    690694<iref primary="true" item="non-transforming proxy"/>
    691    An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed
     695   An HTTP-to-HTTP proxy is called a "<x:dfn>transforming proxy</x:dfn>" if it is designed
    692696   or configured to modify request or response messages in a semantically
    693697   meaningful way (i.e., modifications, beyond those required by normal
    … …  
    701705   organization) that selected the proxy and are beyond the scope of
    702706   this specification.  However, when a proxy is not intended to transform
    703    a given message, we use the term "non-transforming proxy" to target
     707   a given message, we use the term "<x:dfn>non-transforming proxy</x:dfn>" to target
    704708   requirements that preserve HTTP message semantics.
    705709</t>
    706710<t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/>
    707711<iref primary="true" item="accelerator"/>
    708    A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts
     712   A "<x:dfn>gateway</x:dfn>" (a.k.a., "<x:dfn>reverse proxy</x:dfn>")
     713   is a receiving agent that acts
    709714   as a layer above some other server(s) and translates the received
    710715   requests to the underlying server's protocol.  Gateways are often
    711716   used to encapsulate legacy or untrusted information services, to
    712    improve server performance through "accelerator" caching, and to
     717   improve server performance through "<x:dfn>accelerator</x:dfn>" caching, and to
    713718   enable partitioning or load-balancing of HTTP services across
    714719   multiple machines.
    … …  
    729734</t>
    730735<t><iref primary="true" item="tunnel"/>
    731    A "tunnel" acts as a blind relay between two connections
     736   A "<x:dfn>tunnel</x:dfn>" acts as a blind relay between two connections
    732737   without changing the messages. Once active, a tunnel is not
    733738   considered a party to the HTTP communication, though the tunnel might
    … …  
    744749   filters or redirecting agents (usually violating HTTP semantics,
    745750   causing security problems, and otherwise making a mess of things).
    746    Such a network intermediary, often referred to as an "interception proxy"
    747    <xref target="RFC3040"/>, "transparent proxy" <xref target="RFC1919"/>,
    748    or "captive portal",
     751   Such a network intermediary, often referred to as an "<x:dfn>interception proxy</x:dfn>"
     752   <xref target="RFC3040"/>, "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/>,
     753   or "<x:dfn>captive portal</x:dfn>",
    749754   differs from an HTTP proxy because it has not been selected by the client.
    750755   Instead, the network intermediary redirects outgoing TCP port 80 packets
    … …  
    761766<iref primary="true" item="cache"/>
    762767<t>
    763    A "cache" is a local store of previous response messages and the
     768   A "<x:dfn>cache</x:dfn>" is a local store of previous response messages and the
    764769   subsystem that controls its message storage, retrieval, and deletion.
    765770   A cache stores cacheable responses in order to reduce the response
    … …  
    781786</artwork></figure>
    782787<t><iref primary="true" item="cacheable"/>
    783    A response is "cacheable" if a cache is allowed to store a copy of
     788   A response is "<x:dfn>cacheable</x:dfn>" if a cache is allowed to store a copy of
    784789   the response message for use in answering subsequent requests.
    785790   Even when a response is cacheable, there might be additional
Note: See TracChangeset for help on using the changeset viewer.