* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 761


Ignore:
Timestamp:
2010-02-17 05:53:37 (4 years ago)
Author:
julian.reschke@gmx.de
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.