Changeset 1833

Timestamp:

20/08/12 00:10:23 (10 years ago)

Author:

fielding@…

Message:

mark-up some definitions and clarify a heading

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (6 diffs)
• p1-messaging.xml (modified) (5 diffs)

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

@@ -639 +639 @@
                <li><a href="#rfc.section.5.4">5.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.host">Host</a></li>
                <li><a href="#rfc.section.5.5">5.5</a>&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
-               <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#intermediary.forwarding">Intermediary Forwarding</a><ul>
+               <li><a href="#rfc.section.5.6">5.6</a>&nbsp;&nbsp;&nbsp;<a href="#message.forwarding">Message Forwarding</a><ul>
                      <li><a href="#rfc.section.5.6.1">5.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#end-to-end.and.hop-by-hop.header-fields">End-to-end and Hop-by-hop Header Fields</a></li>
                      <li><a href="#rfc.section.5.6.2">5.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#non-modifiable.header-fields">Non-modifiable Header Fields</a></li>
@@ -1700 +1700 @@
       </p>
       <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
-         are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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.8</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
-         to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
-         identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><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>).
+         are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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.8</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 identifier component, if any, since fragment identifiers are reserved
+         for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><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>).
       </p>
       <p id="rfc.section.5.1.p.3">HTTP intermediaries obtain the request semantics and target URI from the request-line of an incoming request message.</p>
@@ -1751 +1750 @@
          <p id="rfc.section.5.3.p.9"><span id="rfc.iref.a.2"></span> When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client <em class="bcp14">MUST</em> send the target URI in absolute-form as the request-target. The proxy is requested to either service that request from a valid
             cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to
-            the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#intermediary.forwarding" title="Intermediary Forwarding">Section&nbsp;5.6</a>.
+            the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in <a href="#message.forwarding" title="Message Forwarding">Section&nbsp;5.6</a>.
          </p>
       </div>
@@ -1809 +1808 @@
       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
       <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request.
-         The URI derived from this reconstruction process is referred to as the "effective request URI".
+         The URI derived from this reconstruction process is referred to as the "<dfn>effective request URI</dfn>".
       </p>
       <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
@@ -1844 +1843 @@
          the effective request URI's authority component.
       </p>
-      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="intermediary.forwarding" href="#intermediary.forwarding">Intermediary Forwarding</a></h2>
+      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="message.forwarding" href="#message.forwarding">Message Forwarding</a></h2>
       <p id="rfc.section.5.6.p.1">As described in <a href="#intermediaries" title="Intermediaries">Section&nbsp;2.4</a>, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used
          to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has
@@ -1852 +1851 @@
       <p id="rfc.section.5.6.p.2">In order to avoid request loops, a proxy that forwards requests to other proxies <em class="bcp14">MUST</em> be able to recognize and exclude all of its own server names, including any aliases, local variations, or literal IP addresses.
       </p>
-      <p id="rfc.section.5.6.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 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.
-      </p>
-      <p id="rfc.section.5.6.p.4">A non-transforming proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
+      <p id="rfc.section.5.6.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.
+      </p>
+      <p id="rfc.section.5.6.p.4">A non-transforming proxy <em class="bcp14">MUST NOT</em> modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server,
          except as noted above to replace an empty path with "/" or "*".
       </p>

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

@@ -2145 +2145 @@
    <xref target="Part2"/>, and a target resource upon which to apply those
    semantics.  A URI reference (<xref target="uri"/>) is typically used as
-   an identifier for the "target resource", which a user agent would resolve
-   to its absolute form in order to obtain the "target URI".  The target URI
+   an identifier for the "<x:dfn>target resource</x:dfn>", which a user agent
+   would resolve to its absolute form in order to obtain the
+   "<x:dfn>target URI</x:dfn>".  The target URI
    excludes the reference's fragment identifier component, if any,
    since fragment identifiers are reserved for client-side processing
@@ -2246 +2247 @@
    the next inbound proxy server or directly to the origin server indicated
    by the request-target.  Requirements on such "forwarding" of messages are
-   defined in <xref target="intermediary.forwarding"/>.
+   defined in <xref target="message.forwarding"/>.
 </t>
 <t>
@@ -2374 +2375 @@
    connection context, in order to identify the intended target resource and
    properly service the request. The URI derived from this reconstruction
-   process is referred to as the "effective request URI".
+   process is referred to as the "<x:dfn>effective request URI</x:dfn>".
 </t>
 <t>
@@ -2457 +2458 @@
 </section>
 
-<section title="Intermediary Forwarding" anchor="intermediary.forwarding">
+<section title="Message Forwarding" anchor="message.forwarding">
 <t>
    As described in <xref target="intermediaries"/>, intermediaries can serve
@@ -2474 +2475 @@
 <t>
    If a proxy receives a request-target with a host name that is not a
-   fully qualified domain name, it &MAY; add its domain to the host name
+   fully qualified domain name, it &MAY; add its own domain to the host name
    it received when forwarding the request.  A proxy &MUST-NOT; change the
    host name if it is a fully qualified domain name.
 </t>
 <t>
-   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
+   A non-transforming proxy &MUST-NOT; modify the "path-absolute" and "query"
    parts of the received request-target when forwarding it to the next inbound
    server, except as noted above to replace an empty path with "/" or "*".