Ignore:
Timestamp:
Jan 22, 2008, 6:11:10 PM (12 years ago)
Author:
fielding@…
Message:

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

File:
1 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>
Note: See TracChangeset for help on using the changeset viewer.