Ignore:
Timestamp:
26/01/12 14:54:04 (10 years ago)
Author:
julian.reschke@…
Message:

spelling & grammar

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1511 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 28, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2012-01-25">
     410      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: July 28, 2012</td>
     442               <td class="left">Expires: July 29, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">January 25, 2012</td>
     495               <td class="right">January 26, 2012</td>
    496496            </tr>
    497497         </tbody>
    … …  
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on July 28, 2012.</p>
     528      <p>This Internet-Draft will expire on July 29, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    10531053         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10541054      </p>
    1055       <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
     1055      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
    10561056         understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
    10571057         message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
    … …  
    19641964            request includes a request body, and the server responds with a final status code before reading the entire request body from
    19651965            the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    1966             the client might not reliably receive the response message. However, this requirement is not be construed as preventing a
    1967             server from defending itself against denial-of-service attacks, or from badly broken client implementations.
     1966            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
     1967            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    19681968         </li>
    19691969      </ul>
    … …  
    21382138      <div id="rfc.iref.h.10"></div>
    21392139      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    2140       <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
    2141          it is willing to accept trailer fields in a chunked transfer-coding.
     2140      <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
     2141         or not it is willing to accept trailer fields in a chunked transfer-coding.
    21422142      </p>
    21432143      <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    … …  
    21802180         </li>
    21812181      </ol>
    2182       <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
    2183          is always acceptable.
     2182      <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
     2183         no transfer-coding is always acceptable.
    21842184      </p>
    21852185      <div id="rfc.iref.t.6"></div>
    … …  
    22252225</pre><p id="rfc.section.8.7.p.3">For example,</p>
    22262226      <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
     2227</pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    22282228         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    22292229         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    26482648         configuration options they provide to proxy operators (especially the default configuration).
    26492649      </p>
    2650       <p id="rfc.section.10.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
     2650      <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve
    26512651         this problem.
    26522652      </p>
    … …  
    29182918         designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
    29192919         any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood
    2920          (or safely ignored) by HTTP/1.0 clients. Likewise, would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
     2920         (or safely ignored) by HTTP/1.0 clients. Likewise, we would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
    29212921      </p>
    29222922      <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts
Note: See TracChangeset for help on using the changeset viewer.