Ignore:
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:
8 edited

Legend:

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

    r171 r172  
    792792      </dl>
    793793      <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>
    794       <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,
    795          URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible
    796          body content over a connection with a server. The server responds with a status line, including the message's protocol version
    797          and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible
    798          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>.
     794      <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
     795         version, followed by a MIME-like message containing request modifiers, client information, and possible body content over
     796         a connection with a server. The server responds with a status line, including the message's protocol version and a success
     797         or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body
     798         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>.
    799799      </p>
    800800      <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
     
    10191019         "rel_path", "query", and "authority" from that specification.
    10201020      </p>
    1021       <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>).
     1021      <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>).
    10221022      </p>
    10231023      <p id="rfc.section.3.2.1.p.3"> </p>
     
    18621862      <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>
    18631863      <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,
    1864          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
    1865          recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers
    1866          and implementors be particularly careful in this area. History shows that errors in this area often create serious security
    1867          and/or privacy problems and generate highly adverse publicity for the implementor's company.
     1864         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
     1865         be provided for the user to control dissemination of such information, and that designers and implementors be particularly
     1866         careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate
     1867         highly adverse publicity for the implementor's company.
    18681868      </p>
    18691869      <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>
    18701870      <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
    18711871         of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries.
    1872          People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without
    1873          the permission of any individuals that are identifiable by the published results.
     1872         People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission
     1873         of any individuals that are identifiable by the published results.
    18741874      </p>
    18751875      <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>
     
    19261926         Internet mail message formats.
    19271927      </p>
    1928       <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
    1929          many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for
    1930          the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny,
    1931          John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett,
    1932          Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
     1928      <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
     1929         who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success
     1930         of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks,
     1931         Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders,
     1932         and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
    19331933      </p>
    19341934      <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
     
    21562156            <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>
    21572157      <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>
    2158       <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"
    2159          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>.
     2158      <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
     2159         "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>.
    21602160      </p>
    21612161      <div id="rfc.iref.m.2"></div>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r171 r172  
    556556<section title="Overall Operation" anchor="intro.overall.operation">
    557557<t>
    558    The HTTP protocol is a request/response protocol. A client sends a
     558   HTTP is a request/response protocol. A client sends a
    559559   request to the server in the form of a request method, URI, and
    560560   protocol version, followed by a MIME-like message containing request
     
    10311031</t>
    10321032<t>
    1033    The HTTP protocol does not place any a priori limit on the length of
     1033   HTTP does not place any a priori limit on the length of
    10341034   a URI. Servers &MUST; be able to handle the URI of any resource they
    10351035   serve, and &SHOULD; be able to handle URIs of unbounded length if they
     
    27452745   (e.g. the user's name, location, mail address, passwords, encryption
    27462746   keys, etc.), and &SHOULD; be very careful to prevent unintentional
    2747    leakage of this information via the HTTP protocol to other sources.
     2747   leakage of this information.
    27482748   We very strongly recommend that a convenient interface be provided
    27492749   for the user to control dissemination of such information, and that
     
    27612761   interest. This information is clearly confidential in nature and its
    27622762   handling can be constrained by law in certain countries. People using
    2763    the HTTP protocol to provide data are responsible for ensuring that
     2763   HTTP to provide data are responsible for ensuring that
    27642764   such material is not distributed without the permission of any
    27652765   individuals that are identifiable by the published results.
     
    28812881</t>
    28822882<t>
    2883    The HTTP protocol has evolved considerably over the years. It has
     2883   HTTP has evolved considerably over the years. It has
    28842884   benefited from a large and active developer community--the many
    28852885   people who have participated on the www-talk mailing list--and it is
     
    36643664<section title="Internet Media Types" anchor="internet.media.type.http">
    36653665<t>
    3666    In addition to defining the HTTP/1.1 protocol, this document serves
     3666   In addition to defining HTTP/1.1, this document serves
    36673667   as the specification for the Internet media type "message/http" and
    36683668   "application/http". The following is to be registered with IANA <xref target="RFC4288"/>.
  • draft-ietf-httpbis/latest/p2-semantics.html

    r170 r172  
    13421342      <div id="rfc.iref.s.41"></div>
    13431343      <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>
    1344       <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
     1344      <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
    13451345         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    13461346         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.
     
    15461546      <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.
    15471547      </p>
    1548       <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.
    1549          Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third
    1550          parties. Servers can use POST-based form submission instead
     1548      <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
     1549         in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might
     1550         be visible to third parties. Such services can use POST-based form submission instead.
    15511551      </p>
    15521552      <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

    r170 r172  
    16271627  <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/>
    16281628<t>
    1629    The server does not support, or refuses to support, the HTTP protocol
     1629   The server does not support, or refuses to support, the protocol
    16301630   version that was used in the request message. The server is
    16311631   indicating that it is unable or unwilling to complete the request
     
    20552055</t>
    20562056<t>
    2057    Clients &SHOULD-NOT;  include a Referer header field in a (non-secure)
     2057   Clients &SHOULD-NOT; include a Referer header field in a (non-secure)
    20582058   HTTP request if the referring page was transferred with a secure
    20592059   protocol.
    20602060</t>
    20612061<t>
    2062    Authors of services which use the HTTP protocol &SHOULD-NOT;  use GET
    2063    based forms for the submission of sensitive data, because this will
    2064    cause this data to be encoded in the Request-URI. Many existing
    2065    servers, proxies, and user agents will log the request URI in some
    2066    place where it might be visible to third parties. Servers can use
    2067    POST-based form submission instead
     2062   Authors of services should not use
     2063   GET-based forms for the submission of sensitive data because that
     2064   data will be encoded in the Request-URI. Many existing
     2065   servers, proxies, and user agents log or display the Request-URI in
     2066   places where it might be visible to third parties. Such services can
     2067   use POST-based form submission instead.
    20682068</t>
    20692069</section>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r170 r172  
    624624      <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.
    625625      </p>
    626       <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,
    627          depending on whether the comparison context allows the use of weak validators or not:
     626      <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
     627         on whether the comparison context allows the use of weak validators or not:
    628628      </p>
    629629      <ul>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r170 r172  
    402402</t>
    403403<t>
    404    The only function that the HTTP/1.1 protocol defines on validators is
     404   The only function that HTTP/1.1 defines on validators is
    405405   comparison. There are two validator comparison functions, depending
    406406   on whether the comparison context allows the use of weak validators
  • draft-ietf-httpbis/latest/p6-cache.html

    r170 r172  
    934934         origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call
    935935         this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if
    936          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
    937          HTTP/1.1 protocol supports the use of conditional methods.
     936         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
     937         supports the use of conditional methods.
    938938      </p>
    939939      <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
     
    10291029      </p>
    10301030      <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>
    1031       <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.
    1032          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.
     1031      <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
     1032         proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.
    10331033      </p>
    10341034      <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:
     
    11551155         the origin server would return for a new request on that resource.
    11561156      </p>
    1157       <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
    1158          that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However,
    1159          several rules help reduce the likelihood of erroneous behavior.
     1157      <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
     1158         the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules
     1159         help reduce the likelihood of erroneous behavior.
    11601160      </p>
    11611161      <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
     
    12771277</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
    12781278         such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest
    1279          of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol
    1280          might apply these directives to header fields not defined in HTTP/1.1.
     1279         of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply
     1280         these directives to header fields not defined in HTTP/1.1.
    12811281      </p>
    12821282      <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

    r170 r172  
    964964   retransmitting the full response if the cached entry is good, and we
    965965   do not want to pay the overhead of an extra round trip if the cached
    966    entry is invalid, the HTTP/1.1 protocol supports the use of
     966   entry is invalid, HTTP/1.1 supports the use of
    967967   conditional methods.
    968968</t>
     
    11411141<section title="Non-modifiable Headers" anchor="non-modifiable.headers">
    11421142<t>
    1143    Some features of the HTTP/1.1 protocol, such as Digest
     1143   Some features of HTTP/1.1, such as Digest
    11441144   Authentication, depend on the value of certain end-to-end headers. A
    11451145   transparent proxy &SHOULD-NOT;  modify an end-to-end header unless the
     
    13931393</t>
    13941394<t>
    1395    There is no way for the HTTP protocol to guarantee that all such
     1395   There is no way for HTTP to guarantee that all such
    13961396   cache entries are marked invalid. For example, the request that
    13971397   caused the change at the origin server might not have gone through
     
    16091609   the named field or fields, and not to the rest of the request or
    16101610   response. This mechanism supports extensibility; implementations of
    1611    future versions of the HTTP protocol might apply these directives to
     1611   future versions of HTTP might apply these directives to
    16121612   header fields not defined in HTTP/1.1.
    16131613</t>
Note: See TracChangeset for help on using the changeset viewer.