Changeset 809 for draft-ietf-httpbis/latest

Timestamp:

13/04/10 13:20:33 (11 years ago)

Author:

julian.reschke@…

Message:

add paragraph break for clarity (related to #196)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (9 diffs)
• p1-messaging.xml (modified) (1 diff)

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

@@ -404 +404 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-04-11">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-04-13">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
@@ -435 +435 @@
             </tr>
             <tr>
-               <td class="left">Expires: October 13, 2010</td>
+               <td class="left">Expires: October 15, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">April 11, 2010</td>
+               <td class="right">April 13, 2010</td>
             </tr>
          </tbody>
@@ -516 +516 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in October 13, 2010.</p>
+      <p>This Internet-Draft will expire in October 15, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1308 +1308 @@
                  / ( <a href="#uri" class="smpl">path-absolute</a> [ "?" <a href="#uri" class="smpl">query</a> ] )
                  / <a href="#uri" class="smpl">authority</a>
-</pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request. The asterisk "*" means that the request does
-         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
-         apply to a resource. One example would be
+</pre><p id="rfc.section.4.1.2.p.3">The four options for request-target are dependent on the nature of the request.</p>
+      <p id="rfc.section.4.1.2.p.4">The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed
+         when the method used does not necessarily apply to a resource. One example would be
       </p>
       <div id="rfc.figure.u.35"></div><pre class="text2">OPTIONS * HTTP/1.1
-</pre><p id="rfc.section.4.1.2.p.5">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
+</pre><p id="rfc.section.4.1.2.p.6">The absolute-URI form is <em class="bcp14">REQUIRED</em> when the request is being made to a proxy. The proxy is requested to forward the request or service it from a valid cache,
          and return the response. Note that the proxy <em class="bcp14">MAY</em> forward the request on to another proxy or directly to the server specified by the absolute-URI. In order to avoid request
          loops, a proxy <em class="bcp14">MUST</em> be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example
@@ -1319 +1319 @@
       </p>
       <div id="rfc.figure.u.36"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
-</pre><p id="rfc.section.4.1.2.p.7">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
-      </p>
-      <p id="rfc.section.4.1.2.p.8">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
-      </p>
-      <p id="rfc.section.4.1.2.p.9">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
+</pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
+      </p>
+      <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      </p>
+      <p id="rfc.section.4.1.2.p.10">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
          absolute path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>, path-absolute) as the request-target, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin
          server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
@@ -1329 +1329 @@
       <div id="rfc.figure.u.37"></div><pre class="text2">GET /pub/WWW/TheProject.html HTTP/1.1
 Host: www.example.org
-</pre><p id="rfc.section.4.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
+</pre><p id="rfc.section.4.1.2.p.12">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original
          URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
       </p>
-      <p id="rfc.section.4.1.2.p.12">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
+      <p id="rfc.section.4.1.2.p.13">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the
          asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target.
       </p>
@@ -1341 +1341 @@
 Host: www.example.org:8001
 </pre>  <p>after connecting to port 8001 of host "www.example.org".</p> 
-      <p id="rfc.section.4.1.2.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
-      </p>
-      <p id="rfc.section.4.1.2.p.16">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted
+      <p id="rfc.section.4.1.2.p.16">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>. If the request-target is percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code.
+      </p>
+      <p id="rfc.section.4.1.2.p.17">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted
          above to replace a null path-absolute with "/".
       </p>
-      <div class="note" id="rfc.section.4.1.2.p.17"> 
+      <div class="note" id="rfc.section.4.1.2.p.18"> 
          <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
             a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
@@ -1352 +1352 @@
          </p> 
       </div>
-      <p id="rfc.section.4.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
+      <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
-      <p id="rfc.section.4.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
+      <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
       </p>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>

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

@@ -1441 +1441 @@
 <t>
    The four options for request-target are dependent on the nature of the
-   request. The asterisk "*" means that the request does not apply to a
+   request.
+</t>   
+<t>
+   The asterisk "*" means that the request does not apply to a
    particular resource, but to the server itself, and is only allowed
    when the method used does not necessarily apply to a resource. One