Changeset 970 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 31/07/10 08:54:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r968 r970 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-3 0">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 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 31, 2011</td>436 <td class="left">Expires: February 1, 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 3 0, 2010</td>489 <td class="right">July 31, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 31, 2011.</p>516 <p>This Internet-Draft will expire in February 1, 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> … … 938 938 <div id="rfc.iref.s.1"></div> 939 939 <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> 940 <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 941 careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or 942 others. 940 <p id="rfc.section.7.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow 941 the user to be aware of any actions they take which might have an unexpected significance to themselves or others. 943 942 </p> 944 943 <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 … … 1225 1224 </p> 1226 1225 <div class="note" id="rfc.section.8.3.p.2"> 1227 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation.1226 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation. 1228 1227 </p> 1229 1228 </div> … … 1635 1634 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. 1636 1635 It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 1637 where they allow links from (so-called "deep linking"), but it should be noted that legitimate requests are not required to 1638 contain a Referer header field. 1636 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 1639 1637 </p> 1640 1638 <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), … … 1705 1703 <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section 2.1</a> of this document. 1706 1704 </p> 1707 <p id="rfc.section.10.1.p.2">The HTTP Method Registry sh ouldbe created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below:1705 <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>> and be populated with the registrations below: 1708 1706 </p> 1709 1707 <div id="rfc.table.1"> … … 1772 1770 <p id="rfc.section.10.2.p.1">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.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.1</a> of this document. 1773 1771 </p> 1774 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:1772 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1775 1773 </p> 1776 1774 <div id="rfc.table.2"> … … 2005 2003 </div> 2006 2004 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2007 <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):2005 <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2008 2006 </p> 2009 2007 <div id="rfc.table.3"> … … 2128 2126 <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 2129 2127 </p> 2130 <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded2131 in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it2132 might be visible to third parties.Such services can use POST-based form submission instead.2128 <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing 2129 servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. 2130 Such services can use POST-based form submission instead. 2133 2131 </p> 2134 2132 <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.