Ignore:
Timestamp:
06/05/14 16:20:31 (6 years ago)
Author:
julian.reschke@…
Message:

mainly grammatical fixes (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2645 r2647  
    789789            request, parses each message received, interprets the message semantics in relation to the identified request target, and
    790790            responds to that request with one or more response messages. A client constructs request messages to communicate specific
    791             intentions, and examines received responses to see if the intentions were carried out, and determine how to interpret the
    792             results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.
     791            intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results.
     792            This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.
    793793         </p>
    794794         <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).
     
    843843            of representation data.
    844844         </p>
    845          <p id="rfc.section.3.p.3">An origin server might be provided with, or capable of generating, multiple representations that are each intended to reflect
     845         <p id="rfc.section.3.p.3">An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect
    846846            the current state of a <a href="#resources" class="smpl">target resource</a>. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to
    847847            a given request, usually based on <a href="#content.negotiation" class="smpl">content negotiation</a>. This "<dfn>selected representation</dfn>" is used to provide the data and metadata for evaluating conditional requests <a href="#RFC7232" id="rfc.xref.RFC7232.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[RFC7232]</cite></a> and constructing the payload for <a href="#status.200" class="smpl">200 (OK)</a> and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>).
     
    902902                     of a media-type, depending on its definition within the media type registry.
    903903                  </p>
    904                   <p id="rfc.section.3.1.1.1.p.6">A parameter value that matches the <a href="#imported.abnf" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
     904                  <p id="rfc.section.3.1.1.1.p.6">A parameter value that matches the <a href="#imported.abnf" class="smpl">token</a> production can be transmitted either as a token or within a quoted-string. The quoted and unquoted values are equivalent.
    905905                     For example, the following examples are all equivalent, but the first is preferred for consistency:
    906906                  </p>
     
    922922                  </p>
    923923                  <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#charset" class="smpl">charset</a> = <a href="#imported.abnf" class="smpl">token</a>
    924 </pre><p id="rfc.section.3.1.1.2.p.3">Charset names ought to be registered in IANA Character Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;) according to the procedures defined in <a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>.
     924</pre><p id="rfc.section.3.1.1.2.p.3">Charset names ought to be registered in the IANA Character Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;) according to the procedures defined in <a href="#RFC2978" id="rfc.xref.RFC2978.1"><cite title="IANA Charset Registration Procedures">[RFC2978]</cite></a>.
    925925                  </p>
    926926               </div>
     
    15531553                  to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request)
    15541554                  and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation
    1555                   body it has in memory remains current as a result of the PUT, thus not in need of retrieving again from the origin server,
     1555                  body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server,
    15561556                  and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental
    15571557                  overwrites (<a href="#request.conditionals" title="Conditionals">Section&nbsp;5.2</a>).
     
    16551655               <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a href="#OPTIONS">OPTIONS</a></h3>
    16561656               <div id="rfc.iref.o.1"></div>
    1657                <p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available for the target resource, either at the origin
     1657               <p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available for the target resource, at either the origin
    16581658                  server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated
    16591659                  with a resource, or the capabilities of a server, without implying a resource action.
     
    22502250               <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#header.user-agent" class="smpl">product</a>         = <a href="#imported.abnf" class="smpl">token</a> ["/" <a href="#header.user-agent" class="smpl">product-version</a>]
    22512251  <a href="#header.user-agent" class="smpl">product-version</a> = <a href="#imported.abnf" class="smpl">token</a>
    2252 </pre><p id="rfc.section.5.5.3.p.5">A sender <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; a sender <em class="bcp14">MUST NOT</em> generate advertising or other non-essential information within the product identifier. A sender <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought to only differ in the product-version
     2252</pre><p id="rfc.section.5.5.3.p.5">A sender <em class="bcp14">SHOULD</em> limit generated product identifiers to what is necessary to identify the product; a sender <em class="bcp14">MUST NOT</em> generate advertising or other non-essential information within the product identifier. A sender <em class="bcp14">SHOULD NOT</em> generate information in <a href="#header.user-agent" class="smpl">product-version</a> that is not a version identifier (i.e., successive versions of the same product name ought only to differ in the product-version
    22532253                  portion of the product identifier).
    22542254               </p>
     
    28262826               <div id="rfc.iref.69"></div>
    28272827               <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a href="#status.400">400 Bad Request</a></h3>
    2828                <p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request due to something which is perceived to be a client
     2828               <p id="rfc.section.6.5.1.p.1">The <dfn>400 (Bad Request)</dfn> status code indicates that the server cannot or will not process the request due to something that is perceived to be a client
    28292829                  error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
    28302830               </p>
     
    32193219               <p id="rfc.section.7.1.2.p.4">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location value refers to the primary resource created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the Location value refers to the preferred target resource for automatically redirecting the request.
    32203220               </p>
    3221                <p id="rfc.section.7.1.2.p.5">If the Location value provided in a <a href="#status.3xx" class="smpl">3xx (Redirection)</a> does not have a fragment component, a user agent <em class="bcp14">MUST</em> process the redirection as if the value inherits the fragment component of the URI reference used to generate the request
     3221               <p id="rfc.section.7.1.2.p.5">If the Location value provided in a <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response does not have a fragment component, a user agent <em class="bcp14">MUST</em> process the redirection as if the value inherits the fragment component of the URI reference used to generate the request
    32223222                  target (i.e., the redirection inherits the original reference's fragment, if any).
    32233223               </p>
     
    35523552            <p id="rfc.section.8.2.p.1">The HTTP Status Code Registry defines the name space for the response status-code token (<a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>). The status code registry is maintained at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt;.
    35533553            </p>
    3554             <p id="rfc.section.8.2.p.2">This Section replaces the registration procedure for HTTP Status Codes previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>.
     3554            <p id="rfc.section.8.2.p.2">This section replaces the registration procedure for HTTP Status Codes previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>.
    35553555            </p>
    35563556            <div id="status.code.registry.procedure">
     
    38403840               <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>.
    38413841               </p>
    3842                <p id="rfc.section.8.3.1.p.3">Authors of specifications defining new fields are advised to keep the name as short as practical and to not prefix the name
    3843                   with "X-" unless the header field will never be used on the Internet. (The "x-" prefix idiom has been extensively misused
     3842               <p id="rfc.section.8.3.1.p.3">Authors of specifications defining new fields are advised to keep the name as short as practical and not to prefix the name
     3843                  with "X-" unless the header field will never be used on the Internet. (The "X-" prefix idiom has been extensively misused
    38443844                  in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet
    3845                   processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see <a href="#BCP178" id="rfc.xref.BCP178.1"><cite title="Deprecating the &#34;X-&#34; Prefix and Similar Constructs in Application Protocols">[BCP178]</cite></a> for further information)
     3845                  processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see <a href="#BCP178" id="rfc.xref.BCP178.1"><cite title="Deprecating the &#34;X-&#34; Prefix and Similar Constructs in Application Protocols">[BCP178]</cite></a> for further information).
    38463846               </p>
    38473847               <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF List Extension: #rule">Section 7</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters
     
    41414141            </p>
    41424142            <p id="rfc.section.9.1.p.2">For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level
    4143                above the current one, and use specially named paths or file names to send data to system devices. Similar naming conventions
     4143               above the current one, and they use specially named paths or file names to send data to system devices. Similar naming conventions
    41444144               might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness
    41454145               over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization
     
    44514451         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
    44524452         <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.7"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> to allow a message body to be transmitted in an open variety of representations and with extensible header fields. However,
    4453             RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email, and hence HTTP has
     4453            RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email; hence, HTTP has
    44544454            features that differ from MIME. These differences were carefully chosen to optimize performance over binary connections, to
    44554455            allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some
Note: See TracChangeset for help on using the changeset viewer.