Changeset 761


Ignore:
Timestamp:
Feb 17, 2010, 5:53:37 AM (10 years ago)
Author:
julian.reschke@…
Message:

lang/grammar

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r756 r761  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-02-02">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-02-17">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: August 6, 2010</td>
     437               <td class="left">Expires: August 21, 2010</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">February 2, 2010</td>
     490               <td class="right">February 17, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    520520      <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>.
    521521      </p>
    522       <p>This Internet-Draft will expire in August 6, 2010.</p>
     522      <p>This Internet-Draft will expire in August 21, 2010.</p>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    12401240            <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting
    12411241               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
    1242                byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.
     1242               byte-range specifiers from a HTTP/1.1 client implies that the client can parse multipart/byteranges responses.
    12431243            </p>
    12441244            <ul class="empty">
    1245                <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.
     1245               <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.
    12461246               </li>
    12471247            </ul>
     
    16531653      <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>
    16541654      <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
    1655          servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
     1655         servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client
    16561656         to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
    16571657         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>.
     
    16851685      <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>
    16861686      <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
    1687          "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.
     1687         "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".
    16881688      </p>
    16891689      <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
     
    21292129         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.
    21302130      </p>
    2131       <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.
     2131      <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.
    21322132      </p>
    21332133      <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
     
    24712471      <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
    24722472         sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
    2473          and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed
    2474          and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
     2473         and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use should
     2474         be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
    24752475      </p>
    24762476      <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
    24772477         configuration options they provide to proxy operators (especially the default configuration).
    24782478      </p>
    2479       <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
     2479      <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
    24802480         this problem.
    24812481      </p>
     
    27292729         can be interpreted unambiguously.
    27302730      </p>
    2731       <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.
     2731      <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.
    27322732      </p>
    27332733      <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,
     
    28072807         clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0
    28082808         experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify
    2809          these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand
    2810          Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection
    2811          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
    2812          from using Keep-Alive when talking to proxies.
     2809         these problems. The problem was that some existing HTTP/1.0 clients may be sending Keep-Alive to a proxy server that doesn't
     2810         understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive
     2811         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
     2812         must be prevented from using Keep-Alive when talking to proxies.
    28132813      </p>
    28142814      <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.
     
    28482848      <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>)
    28492849      </p>
    2850       <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>)
     2850      <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>)
    28512851      </p>
    28522852      <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>)
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r756 r761  
    13131313     &MUST-NOT; be used unless the sender knows that the recipient can parse
    13141314     it; the presence in a request of a Range header with multiple byte-range
    1315      specifiers from a 1.1 client implies that the client can parse
     1315     specifiers from a HTTP/1.1 client implies that the client can parse
    13161316     multipart/byteranges responses.
    13171317    <list style="empty"><t>
    1318        A range header might be forwarded by a 1.0 proxy that does not
     1318       A range header might be forwarded by a HTTP/1.0 proxy that does not
    13191319       understand multipart/byteranges; in this case the server &MUST;
    13201320       delimit the message using methods defined in items 1, 3 or 5 of
     
    21162116   established to fetch each URL, increasing the load on HTTP servers
    21172117   and causing congestion on the Internet. The use of inline images and
    2118    other associated data often require a client to make multiple
     2118   other associated data often requires a client to make multiple
    21192119   requests of the same server in a short amount of time. Analysis of
    21202120   these performance problems and results from a prototype
     
    21852185   chooses to close the connection immediately after sending the
    21862186   response, it &SHOULD; send a Connection header including the
    2187    connection-token close.
     2187   connection-token "close".
    21882188</t>
    21892189<t>
     
    31013101</t>
    31023102<t>
    3103    Multiple Via field values represents each proxy or gateway that has
     3103   Multiple Via field values represent each proxy or gateway that has
    31043104   forwarded the message. Each recipient &MUST; append its information
    31053105   such that the end result is ordered according to the sequence of
     
    35713571   contains highly sensitive personal information, and/or information
    35723572   about organizations. Log information should be carefully guarded, and
    3573    appropriate guidelines for use developed and followed. (<xref target="abuse.of.server.log.information"/>).
     3573   appropriate guidelines for use should be developed and followed.
     3574   (<xref target="abuse.of.server.log.information"/>).
    35743575</t>
    35753576<t>
     
    35803581</t>
    35813582<t>
    3582    Users of a proxy need to be aware that they are no trustworthier than
    3583    the people who run the proxy; HTTP itself cannot solve this problem.
     3583   Users of a proxy need to be aware that proxies are no trustworthier than
     3584   the people who run them; HTTP itself cannot solve this problem.
    35843585</t>
    35853586<t>
     
    44354436<t>
    44364437   Clients &SHOULD; be tolerant in parsing the Status-Line and servers
    4437    tolerant when parsing the Request-Line. In particular, they &SHOULD;
    4438    accept any amount of WSP characters between fields, even though
     4438   &SHOULD; be tolerant when parsing the Request-Line. In particular, they
     4439   &SHOULD; accept any amount of WSP characters between fields, even though
    44394440   only a single SP is required.
    44404441</t>
     
    45794580   experimental implementations of persistent connections are faulty,
    45804581   and the new facilities in HTTP/1.1 are designed to rectify these
    4581    problems. The problem was that some existing 1.0 clients may be
     4582   problems. The problem was that some existing HTTP/1.0 clients may be
    45824583   sending Keep-Alive to a proxy server that doesn't understand
    45834584   Connection, which would then erroneously forward it to the next
     
    46614662</t>
    46624663<t>
    4663   Remove reference to non-existant identity transfer-coding value tokens.
     4664  Remove reference to non-existent identity transfer-coding value tokens.
    46644665  (Sections <xref format="counter" target="transfer.codings"/> and
    46654666  <xref format="counter" target="message.length"/>)
Note: See TracChangeset for help on using the changeset viewer.