Changeset 1521 for draft-ietf-httpbis/latest
- Timestamp:
- 31/01/12 21:30:47 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1520 r1521 358 358 } 359 359 @bottom-center { 360 content: "Expires August 1, 2012";360 content: "Expires August 3, 2012"; 361 361 } 362 362 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2012-01- 29">412 <meta name="dct.issued" scheme="ISO8601" content="2012-01-31"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 414 414 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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."> … … 441 441 </tr> 442 442 <tr> 443 <td class="left">Expires: August 1, 2012</td>443 <td class="left">Expires: August 3, 2012</td> 444 444 <td class="right">HP</td> 445 445 </tr> … … 494 494 <tr> 495 495 <td class="left"></td> 496 <td class="right">January 29, 2012</td>496 <td class="right">January 31, 2012</td> 497 497 </tr> 498 498 </tbody> … … 524 524 in progress”. 525 525 </p> 526 <p>This Internet-Draft will expire on August 1, 2012.</p>526 <p>This Internet-Draft will expire on August 3, 2012.</p> 527 527 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 528 528 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1818 1818 <p id="rfc.section.7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1819 1819 </p> 1820 <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1820 <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1821 the new URI(s). 1821 1822 </p> 1822 1823 <p id="rfc.section.7.3.2.p.4">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which … … 1833 1834 <p id="rfc.section.7.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1834 1835 </p> 1835 <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1836 <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1837 the new URI(s). 1836 1838 </p> 1837 1839 <p id="rfc.section.7.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which … … 1884 1886 <p id="rfc.section.7.3.8.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests. 1885 1887 </p> 1886 <p id="rfc.section.7.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1888 <p id="rfc.section.7.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to 1889 the new URI(s). 1887 1890 </p> 1888 1891 <p id="rfc.section.7.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 6.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which … … 3002 3005 <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.2.4</a>) 3003 3006 </p> 3004 <p id="rfc.section.A.p.6">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3007 <p id="rfc.section.A.p.6">Removed the normative requirements on response payloads for status codes 301, 302, and 307. (<a href="#status.3xx" title="Redirection 3xx">Section 7.3</a>) 3008 </p> 3009 <p id="rfc.section.A.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3005 3010 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3006 3011 the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">7.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.3.8</a>) 3007 3012 </p> 3008 <p id="rfc.section.A.p. 7">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource3013 <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource 3009 3014 must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient 3010 3015 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.3.6</a>) 3011 3016 </p> 3012 <p id="rfc.section.A.p. 8">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.4.19</a>)3013 </p> 3014 <p id="rfc.section.A.p. 9">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3015 </p> 3016 <p id="rfc.section.A.p.1 0">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement3017 <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.4.19</a>) 3018 </p> 3019 <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3020 </p> 3021 <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3017 3022 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 9.1</a>) 3018 3023 </p> 3019 <p id="rfc.section.A.p.1 1">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified3024 <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3020 3025 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.3</a>) 3021 3026 </p> 3022 <p id="rfc.section.A.p.1 2">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred3027 <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3023 3028 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3024 3029 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.5</a>) 3025 3030 </p> 3026 <p id="rfc.section.A.p.1 3">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.6</a>)3027 </p> 3028 <p id="rfc.section.A.p.1 4">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.7</a>)3029 </p> 3030 <p id="rfc.section.A.p.1 5">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated3031 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 9.6</a>) 3032 </p> 3033 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.7</a>) 3034 </p> 3035 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3031 3036 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>) 3032 3037 </p> … … 3440 3445 <p id="rfc.section.C.20.p.1">Closed issues: </p> 3441 3446 <ul> 3447 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/332">http://tools.ietf.org/wg/httpbis/trac/ticket/332</a>>: "relax requirements on hypertext in 3/4/5xx error responses" 3448 </li> 3442 3449 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/333">http://tools.ietf.org/wg/httpbis/trac/ticket/333</a>>: "example for 426 response should have a payload" 3443 3450 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1520 r1521 1770 1770 <t> 1771 1771 The new permanent URI &SHOULD; be given by the Location field in the 1772 response. Unless the request method was HEAD, the representation of the 1773 response &SHOULD; contain a short hypertext note with a hyperlink to 1774 the new URI(s). 1772 response. A response payload can contain a short hypertext note with a 1773 hyperlink to the new URI(s). 1775 1774 </t> 1776 1775 <t> … … 1802 1801 <t> 1803 1802 The temporary URI &SHOULD; be given by the Location field in the 1804 response. Unless the request method was HEAD, the representation of the 1805 response &SHOULD; contain a short hypertext note with a hyperlink to 1806 the new URI(s). 1803 response. A response payload can contain a short hypertext note with a 1804 hyperlink to the new URI(s). 1807 1805 </t> 1808 1806 <t> … … 1906 1904 <t> 1907 1905 The temporary URI &SHOULD; be given by the Location field in the 1908 response. Unless the request method was HEAD, the representation of the 1909 response &SHOULD; contain a short hypertext note with a hyperlink to 1910 the new URI(s). 1906 response. A response payload can contain a short hypertext note with a 1907 hyperlink to the new URI(s). 1911 1908 </t> 1912 1909 <t> … … 3988 3985 </t> 3989 3986 <t> 3987 Removed the normative requirements on response payloads for status codes 3988 301, 302, and 307. 3989 (<xref target="status.3xx"/>) 3990 </t> 3991 <t> 3990 3992 Failed to consider that there are many other request methods that are safe 3991 3993 to automatically redirect, and further that the user agent is able to make … … 4758 4760 <list style="symbols"> 4759 4761 <t> 4762 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/332"/>: 4763 "relax requirements on hypertext in 3/4/5xx error responses" 4764 </t> 4765 <t> 4760 4766 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/333"/>: 4761 4767 "example for 426 response should have a payload"
Note: See TracChangeset
for help on using the changeset viewer.