Ignore:
Timestamp:
07/05/14 12:48:29 (6 years ago)
Author:
julian.reschke@…
Message:

hyphenation (#553)

File:
1 edited

Legend:

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

    r2651 r2652  
    463463  }
    464464  @bottom-center {
    465        content: "Expires November 7, 2014";
     465       content: "Expires November 8, 2014";
    466466  }
    467467  @bottom-right {
     
    507507      <meta name="dct.creator" content="Reschke, J. F.">
    508508      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    509       <meta name="dct.issued" scheme="ISO8601" content="2014-05-06">
     509      <meta name="dct.issued" scheme="ISO8601" content="2014-05-07">
    510510      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    511511      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    535535            <tr>
    536536               <td class="left">Intended status: Standards Track</td>
    537                <td class="right">May 6, 2014</td>
     537               <td class="right">May 7, 2014</td>
    538538            </tr>
    539539            <tr>
    540                <td class="left">Expires: November 7, 2014</td>
     540               <td class="left">Expires: November 8, 2014</td>
    541541               <td class="right"></td>
    542542            </tr>
     
    567567            in progress”.
    568568         </p>
    569          <p>This Internet-Draft will expire on November 7, 2014.</p>
     569         <p>This Internet-Draft will expire on November 8, 2014.</p>
    570570      </div>
    571571      <div id="rfc.copyrightnotice">
     
    12891289                  selection.
    12901290               </p>
    1291                <p id="rfc.section.3.4.2.p.4">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1291               <p id="rfc.section.3.4.2.p.4">Reactive negotiation is advantageous when the response would vary over commonly used dimensions (such as type, language, or
    12921292                  encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    12931293                  when public caches are used to distribute server load and reduce network usage.
     
    13981398               </p>
    13991399               <p id="rfc.section.4.2.1.p.2">This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, not
    1400                   entirely read-only, or which causes side-effects while invoking a safe method. What is important, however, is that the client
     1400                  entirely read-only, or which causes side effects while invoking a safe method. What is important, however, is that the client
    14011401                  did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information
    14021402                  to access log files at the completion of every response, regardless of the method, and that is considered safe even though
    14031403                  the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on
    1404                   the Web will often have the side-effect of charging an advertising account.
     1404                  the Web will often have the side effect of charging an advertising account.
    14051405               </p>
    14061406               <p id="rfc.section.4.2.1.p.3">Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.</p>
     
    14161416                  it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the
    14171417                  purpose of such a resource is to perform an unsafe action, then the resource owner <em class="bcp14">MUST</em> disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate
    1418                   side-effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching,
     1418                  side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching,
    14191419                  building a search index, etc.
    14201420               </p>
     
    14271427               </p>
    14281428               <p id="rfc.section.4.2.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free
    1429                   to log each request separately, retain a revision control history, or implement other non-idempotent side-effects for each
     1429                  to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each
    14301430                  idempotent request.
    14311431               </p>
     
    15671567                  to a different URI, then the origin server <em class="bcp14">MUST</em> send an appropriate <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
    15681568               </p>
    1569                <p id="rfc.section.4.3.4.p.10">A PUT request applied to the target resource can have side-effects on other resources. For example, an article might have
     1569               <p id="rfc.section.4.3.4.p.10">A PUT request applied to the target resource can have side effects on other resources. For example, an article might have
    15701570                  a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version
    15711571                  (different resources that at one point shared the same state as the current version resource). A successful PUT request on
     
    22302230               </p>
    22312231               <p id="rfc.section.5.5.2.p.8">Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the
    2232                   unfortunate side-effect of interfering with protection against CSRF attacks, which can be far more harmful to their users.
     2232                  unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users.
    22332233                  Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes
    22342234                  to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components.
     
    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 only to 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 nonessential 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>
     
    26112611                  in HTTP for re-sending a status code from an asynchronous operation.
    26122612               </p>
    2613                <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process
     2613               <p id="rfc.section.6.3.3.p.2">The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process
    26142614                  (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the
    26152615                  server persist until the process is completed. The representation sent with this response ought to describe the request's
Note: See TracChangeset for help on using the changeset viewer.