![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 902 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 24/07/10 07:25:24 (11 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p2-semantics.html (modified) (12 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r900 r902 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-2 3">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-24"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 "HTTP/1.1" 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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: January 2 4, 2011</td>436 <td class="left">Expires: January 25, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">July 2 3, 2010</td>489 <td class="right">July 24, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 2 4, 2011.</p>516 <p>This Internet-Draft will expire in January 25, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 928 928 </li> 929 929 <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 m aynot be).930 that it is a representation of the resource at the Content-Location URI (but it might not be). 931 931 </li> 932 932 <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> … … 943 943 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="safe.methods" href="#safe.methods">Safe Methods</a></h3> 944 944 <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 themselves946 o r 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. 947 947 </p> 948 948 <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 … … 1296 1296 <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 1297 1297 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 m ay 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 useful1300 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). 1301 1301 </p> 1302 1302 <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. … … 1335 1335 <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 1336 1336 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 m ayerase the client's unacknowledged input buffers before they can be read and interpreted1337 a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted 1338 1338 by the HTTP application. 1339 1339 </p> … … 1384 1384 <div class="note" id="rfc.section.8.4.7.p.3"> 1385 1385 <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 m ay even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of1387 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. 1388 1388 </p> 1389 1389 </div> … … 1502 1502 </p> 1503 1503 <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 m ay wish1505 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. 1506 1506 </p> 1507 1507 </div> … … 1629 1629 <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> 1630 1630 <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 maybe 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> 1632 1632 <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). 1633 1633 </p> … … 2125 2125 has no better mechanism. 2126 2126 </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 7.8</a>) may expose information sent in request headers in theresponse. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect2127 <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 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 2128 2128 data from the client. 2129 2129 </p>
Note: See TracChangeset
for help on using the changeset viewer.
