Changeset 172

Timestamp:

Jan 22, 2008, 6:11:10 PM (12 years ago)

Author:

fielding@…

Message:

editorial: replace redundant "the HTTP protocol" phrases or rephrase

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (6 diffs)
• p2-semantics.html (modified) (2 diffs)
• p2-semantics.xml (modified) (2 diffs)
• p4-conditional.html (modified) (1 diff)
• p4-conditional.xml (modified) (1 diff)
• p6-cache.html (modified) (4 diffs)
• p6-cache.xml (modified) (4 diffs)

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

@@ -792 +792 @@
       </dl>
       <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2>
-      <p id="rfc.section.1.4.p.1">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method,
-         URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible
-         body content over a connection with a server. The server responds with a status line, including the message's protocol version
-         and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible
-         entity-body content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
+      <p id="rfc.section.1.4.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol
+         version, followed by a MIME-like message containing request modifiers, client information, and possible body content over
+         a connection with a server. The server responds with a status line, including the message's protocol version and a success
+         or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body
+         content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
       </p>
       <p id="rfc.section.1.4.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin
@@ -1019 +1019 @@
          "rel_path", "query", and "authority" from that specification.
       </p>
-      <p id="rfc.section.3.2.1.p.2">The HTTP protocol does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      <p id="rfc.section.3.2.1.p.2">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.3.2.1.p.3"> </p>
@@ -1862 +1862 @@
       <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="personal.information" href="#personal.information">Personal Information</a></h2>
       <p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords,
-         encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly
-         recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers
-         and implementors be particularly careful in this area. History shows that errors in this area often create serious security
-         and/or privacy problems and generate highly adverse publicity for the implementor's company.
+         encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface
+         be provided for the user to control dissemination of such information, and that designers and implementors be particularly
+         careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate
+         highly adverse publicity for the implementor's company.
       </p>
       <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2>
       <p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects
          of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries.
-         People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without
-         the permission of any individuals that are identifiable by the published results.
+         People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission
+         of any individuals that are identifiable by the published results.
       </p>
       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2>
@@ -1926 +1926 @@
          Internet mail message formats.
       </p>
-      <p id="rfc.section.11.p.2">The HTTP protocol has evolved considerably over the years. It has benefited from a large and active developer community--the
-         many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for
-         the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny,
-         John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett,
-         Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
+      <p id="rfc.section.11.p.2">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people
+         who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success
+         of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks,
+         Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders,
+         and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
       </p>
       <p id="rfc.section.11.p.3">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already
@@ -2156 +2156 @@
             <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">EMail: <a><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
       <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Types</a></h1>
-      <p id="rfc.section.A.p.1">In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http"
-         and "application/http". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
+      <p id="rfc.section.A.p.1">In addition to defining HTTP/1.1, this document serves as the specification for the Internet media type "message/http" and
+         "application/http". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
       </p>
       <div id="rfc.iref.m.2"></div>

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

@@ -556 +556 @@
 <section title="Overall Operation" anchor="intro.overall.operation">
 <t>
-   The HTTP protocol is a request/response protocol. A client sends a
+   HTTP is a request/response protocol. A client sends a
    request to the server in the form of a request method, URI, and
    protocol version, followed by a MIME-like message containing request
@@ -1031 +1031 @@
 </t>
 <t>
-   The HTTP protocol does not place any a priori limit on the length of
+   HTTP does not place any a priori limit on the length of
    a URI. Servers &MUST; be able to handle the URI of any resource they
    serve, and &SHOULD; be able to handle URIs of unbounded length if they
@@ -2745 +2745 @@
    (e.g. the user's name, location, mail address, passwords, encryption
    keys, etc.), and &SHOULD; be very careful to prevent unintentional
-   leakage of this information via the HTTP protocol to other sources.
+   leakage of this information.
    We very strongly recommend that a convenient interface be provided
    for the user to control dissemination of such information, and that
@@ -2761 +2761 @@
    interest. This information is clearly confidential in nature and its
    handling can be constrained by law in certain countries. People using
-   the HTTP protocol to provide data are responsible for ensuring that
+   HTTP to provide data are responsible for ensuring that
    such material is not distributed without the permission of any
    individuals that are identifiable by the published results.
@@ -2881 +2881 @@
 </t>
 <t>
-   The HTTP protocol has evolved considerably over the years. It has
+   HTTP has evolved considerably over the years. It has
    benefited from a large and active developer community--the many
    people who have participated on the www-talk mailing list--and it is
@@ -3664 +3664 @@
 <section title="Internet Media Types" anchor="internet.media.type.http">
 <t>
-   In addition to defining the HTTP/1.1 protocol, this document serves
+   In addition to defining HTTP/1.1, this document serves
    as the specification for the Internet media type "message/http" and
    "application/http". The following is to be registered with IANA <xref target="RFC4288"/>.

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1342 +1342 @@
       <div id="rfc.iref.s.41"></div>
       <h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
-      <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server
+      <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
          is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
@@ -1546 +1546 @@
       <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
       </p>
-      <p id="rfc.section.12.2.p.3">Authors of services which use the HTTP protocol <em class="bcp14">SHOULD NOT</em> use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI.
-         Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third
-         parties. Servers can use POST-based form submission instead
+      <p id="rfc.section.12.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded
+         in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might
+         be visible to third parties. Such services can use POST-based form submission instead.
       </p>
       <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1627 +1627 @@
   <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/>
 <t>
-   The server does not support, or refuses to support, the HTTP protocol
+   The server does not support, or refuses to support, the protocol
    version that was used in the request message. The server is
    indicating that it is unable or unwilling to complete the request
@@ -2055 +2055 @@
 </t>
 <t>
-   Clients &SHOULD-NOT;  include a Referer header field in a (non-secure)
+   Clients &SHOULD-NOT; include a Referer header field in a (non-secure)
    HTTP request if the referring page was transferred with a secure
    protocol.
 </t>
 <t>
-   Authors of services which use the HTTP protocol &SHOULD-NOT;  use GET
-   based forms for the submission of sensitive data, because this will
-   cause this data to be encoded in the Request-URI. Many existing
-   servers, proxies, and user agents will log the request URI in some
-   place where it might be visible to third parties. Servers can use
-   POST-based form submission instead
+   Authors of services should not use
+   GET-based forms for the submission of sensitive data because that
+   data will be encoded in the Request-URI. Many existing
+   servers, proxies, and user agents log or display the Request-URI in
+   places where it might be visible to third parties. Such services can
+   use POST-based form submission instead.
 </t>
 </section>

draft-ietf-httpbis/latest/p4-conditional.html

@@ -624 +624 @@
       <p id="rfc.section.4.p.6">Clients <em class="bcp14">MAY</em> issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients <em class="bcp14">MUST NOT</em> use weak validators in other forms of request.
       </p>
-      <p id="rfc.section.4.p.7">The only function that the HTTP/1.1 protocol defines on validators is comparison. There are two validator comparison functions,
-         depending on whether the comparison context allows the use of weak validators or not: 
+      <p id="rfc.section.4.p.7">The only function that HTTP/1.1 defines on validators is comparison. There are two validator comparison functions, depending
+         on whether the comparison context allows the use of weak validators or not: 
       </p>
       <ul>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -402 +402 @@
 </t>
 <t>
-   The only function that the HTTP/1.1 protocol defines on validators is
+   The only function that HTTP/1.1 defines on validators is
    comparison. There are two validator comparison functions, depending
    on whether the comparison context allows the use of weak validators

draft-ietf-httpbis/latest/p6-cache.html

@@ -934 +934 @@
          origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call
          this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if
-         the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the
-         HTTP/1.1 protocol supports the use of conditional methods.
+         the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, HTTP/1.1
+         supports the use of conditional methods.
       </p>
       <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server
@@ -1029 +1029 @@
       </p>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2>
-      <p id="rfc.section.6.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers.
-         A transparent proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
+      <p id="rfc.section.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent
+         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
       </p>
       <p id="rfc.section.6.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: 
@@ -1155 +1155 @@
          the origin server would return for a new request on that resource.
       </p>
-      <p id="rfc.section.11.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request
-         that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However,
-         several rules help reduce the likelihood of erroneous behavior.
+      <p id="rfc.section.11.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused
+         the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules
+         help reduce the likelihood of erroneous behavior.
       </p>
       <p id="rfc.section.11.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from
@@ -1277 +1277 @@
 </pre><p id="rfc.section.15.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When
          such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest
-         of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol
-         might apply these directives to header fields not defined in HTTP/1.1.
+         of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply
+         these directives to header fields not defined in HTTP/1.1.
       </p>
       <p id="rfc.section.15.2.p.5">The cache-control directives can be broken down into these general categories: </p>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -964 +964 @@
    retransmitting the full response if the cached entry is good, and we
    do not want to pay the overhead of an extra round trip if the cached
-   entry is invalid, the HTTP/1.1 protocol supports the use of
+   entry is invalid, HTTP/1.1 supports the use of
    conditional methods.
 </t>
@@ -1141 +1141 @@
 <section title="Non-modifiable Headers" anchor="non-modifiable.headers">
 <t>
-   Some features of the HTTP/1.1 protocol, such as Digest
+   Some features of HTTP/1.1, such as Digest
    Authentication, depend on the value of certain end-to-end headers. A
    transparent proxy &SHOULD-NOT;  modify an end-to-end header unless the
@@ -1393 +1393 @@
 </t>
 <t>
-   There is no way for the HTTP protocol to guarantee that all such
+   There is no way for HTTP to guarantee that all such
    cache entries are marked invalid. For example, the request that
    caused the change at the origin server might not have gone through
@@ -1609 +1609 @@
    the named field or fields, and not to the rest of the request or
    response. This mechanism supports extensibility; implementations of
-   future versions of the HTTP protocol might apply these directives to
+   future versions of HTTP might apply these directives to
    header fields not defined in HTTP/1.1.
 </t>