Ignore:
Timestamp:
Jul 24, 2010, 12:25:24 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r900 r902  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-23">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 24, 2011</td>
     436               <td class="left">Expires: January 25, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 23, 2010</td>
     489               <td class="right">July 24, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 24, 2011.</p>
     516      <p>This Internet-Draft will expire in January 25, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    928928         </li>
    929929         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
    930             that it is a representation of the resource at the Content-Location URI (but it may not be).
     930            that it is a representation of the resource at the Content-Location URI (but it might not be).
    931931         </li>
    932932         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
    … …  
    943943      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
    944944      <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
    945          careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves
    946          or others.
     945         careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or
     946         others.
    947947      </p>
    948948      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
    … …  
    12961296      <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
    12971297         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such
    1298          that the follow-on representation may be useful without implying that it adequately represents the previously requested resource.
    1299          Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful
    1300          description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
     1298         that the follow-on representation might be useful without implying that it adequately represents the previously requested
     1299         resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
     1300         be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
    13011301      </p>
    13021302      <p id="rfc.section.8.3.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
    … …  
    13351335      <p id="rfc.section.8.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes
    13361336         the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send
    1337          a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted
     1337         a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted
    13381338         by the HTTP application.
    13391339      </p>
    … …  
    13841384      <div class="note" id="rfc.section.8.4.7.p.3">
    13851385         <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
    1386             In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    1387             an incoming response to determine if it is acceptable.
     1386            In some cases, this might even be preferable to sending a 406 response. User agents are encouraged to inspect the headers
     1387            of an incoming response to determine if it is acceptable.
    13881388         </p>
    13891389      </div>
    … …  
    15021502      </p>
    15031503      <div class="note" id="rfc.section.8.5.4.p.2">
    1504          <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish
    1505             to simply refuse the connection.
     1504         <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers might
     1505            wish to simply refuse the connection.
    15061506         </p>
    15071507      </div>
    … …  
    16291629      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a>   = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a>
    16301630  <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    1631 </pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p>
     1631</pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    16321632      <p id="rfc.section.9.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).
    16331633      </p>
    … …  
    21252125         has no better mechanism.
    21262126      </p>
    2127       <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>) may expose information sent in request headers in the response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
     2127      <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>), expose information that was sent in request headers within the body of their response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
    21282128         data from the client.
    21292129      </p>
Note: See TracChangeset for help on using the changeset viewer.