Changeset 761 for draft-ietf-httpbis/latest/p1-messaging.html

Timestamp:

17/02/10 13:53:37 (12 years ago)

Author:

julian.reschke@…

Message:

lang/grammar

File:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (12 diffs)

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-02-02">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-02-17">
       <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: August 6, 2010</td>
+               <td class="left">Expires: August 21, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -488 +488 @@
             <tr>
                <td class="left"></td>
-               <td class="right">February 2, 2010</td>
+               <td class="right">February 17, 2010</td>
             </tr>
          </tbody>
@@ -520 +520 @@
       <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.
       </p>
-      <p>This Internet-Draft will expire in August 6, 2010.</p>
+      <p>This Internet-Draft will expire in August 21, 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>
@@ -1240 +1240 @@
             <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting
                media type defines the transfer-length. This media type <em class="bcp14">MUST NOT</em> be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple
-               byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses. 
+               byte-range specifiers from a HTTP/1.1 client implies that the client can parse multipart/byteranges responses. 
             </p>
             <ul class="empty">
-               <li>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
+               <li>A range header might be forwarded by a HTTP/1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
                </li>
             </ul>
@@ -1653 +1653 @@
       <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3>
       <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP
-         servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
+         servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client
          to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
          from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
@@ -1685 +1685 @@
       <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a>&nbsp;<a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4>
       <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token
-         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.
+         "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token "close".
       </p>
       <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains
@@ -2129 +2129 @@
          be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol.
       </p>
-      <p id="rfc.section.9.9.p.5">Multiple Via field values represents each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
+      <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.
       </p>
       <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and
@@ -2471 +2471 @@
       <p id="rfc.section.11.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports
          sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
-         and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed
-         and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
+         and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use should
+         be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
       </p>
       <p id="rfc.section.11.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the
          configuration options they provide to proxy operators (especially the default configuration).
       </p>
-      <p id="rfc.section.11.5.p.4">Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve
+      <p id="rfc.section.11.5.p.4">Users of a proxy need to be aware that proxies are no trustworthier than the people who run them; HTTP itself cannot solve
          this problem.
       </p>
@@ -2729 +2729 @@
          can be interpreted unambiguously.
       </p>
-      <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
+      <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers <em class="bcp14">SHOULD</em> be tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.
       </p>
       <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers,
@@ -2807 +2807 @@
          clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
          experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
-         these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand
-         Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection
-         and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented
-         from using Keep-Alive when talking to proxies.
+         these problems. The problem was that some existing HTTP/1.0 clients may be sending Keep-Alive to a proxy server that doesn't
+         understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive
+         connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients
+         must be prevented from using Keep-Alive when talking to proxies.
       </p>
       <p id="rfc.section.B.2.p.2">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable.
@@ -2848 +2848 @@
       <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a>)
       </p>
-      <p id="rfc.section.B.4.p.4">Remove reference to non-existant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.length" title="Message Length">3.4</a>)
+      <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.length" title="Message Length">3.4</a>)
       </p>
       <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)