Changeset 1760 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 11/07/12 15:40:04 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1756 r1760 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 1, 2013";451 content: "Expires January 12, 2013"; 452 452 } 453 453 @bottom-right { … … 497 497 <meta name="dct.creator" content="Reschke, J. F."> 498 498 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 0">499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-11"> 500 500 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 501 501 <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. Furthermore, it defines HTTP message content, metadata, and content negotiation."> … … 528 528 </tr> 529 529 <tr> 530 <td class="left">Expires: January 1 1, 2013</td>530 <td class="left">Expires: January 12, 2013</td> 531 531 <td class="right">greenbytes</td> 532 532 </tr> 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">July 1 0, 2012</td>535 <td class="right">July 11, 2012</td> 536 536 </tr> 537 537 </tbody> … … 563 563 in progress”. 564 564 </p> 565 <p>This Internet-Draft will expire on January 1 1, 2013.</p>565 <p>This Internet-Draft will expire on January 12, 2013.</p> 566 566 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 567 567 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 3937 3937 </p> 3938 3938 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 3939 <p id="rfc.section.C.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 2.3.4</a>) 3940 </p> 3941 <p id="rfc.section.C.p.2">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 2.3.5</a>) 3942 </p> 3943 <p id="rfc.section.C.p.3">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 2.3.8</a>) 3944 </p> 3945 <p id="rfc.section.C.p.4">This document takes over the Status Code Registry, 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.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) 3946 </p> 3947 <p id="rfc.section.C.p.5">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.4.4</a>) 3948 </p> 3949 <p id="rfc.section.C.p.6">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 4.5</a>) 3950 </p> 3951 <p id="rfc.section.C.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3939 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 2.2</a>) 3940 </p> 3941 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section 2.3.4</a>) 3942 </p> 3943 <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section 2.3.5</a>) 3944 </p> 3945 <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section 2.3.8</a>) 3946 </p> 3947 <p id="rfc.section.C.p.5">Take over the Status Code Registry, 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.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 4.2</a>) 3948 </p> 3949 <p id="rfc.section.C.p.6">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 4.4.4</a>) 3950 </p> 3951 <p id="rfc.section.C.p.7">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 4.5</a>) 3952 </p> 3953 <p id="rfc.section.C.p.8">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 3952 3954 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3953 3955 the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>) 3954 3956 </p> 3955 <p id="rfc.section.C.p. 8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through3957 <p id="rfc.section.C.p.9">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through 3956 3958 the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy. 3957 3959 (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>) 3958 3960 </p> 3959 <p id="rfc.section.C.p. 9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (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 4.6.15</a>)3960 </p> 3961 <p id="rfc.section.C.p.1 0">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3962 </p> 3963 <p id="rfc.section.C.p.1 1">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents3961 <p id="rfc.section.C.p.10">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (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 4.6.15</a>) 3962 </p> 3963 <p id="rfc.section.C.p.11">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3964 </p> 3965 <p id="rfc.section.C.p.12">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents 3964 3966 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.5</a>) 3965 3967 </p> 3966 <p id="rfc.section.C.p.1 2">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing3968 <p id="rfc.section.C.p.13">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing 3967 3969 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.11</a>) 3968 3970 </p> 3969 <p id="rfc.section.C.p.1 3">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't3971 <p id="rfc.section.C.p.14">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't 3970 3972 what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 9.13</a>) 3971 3973 </p> 3972 <p id="rfc.section.C.p.1 4">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> 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.14</a>)3973 </p> 3974 <p id="rfc.section.C.p.1 5">Allow <a href="#header.referer" class="smpl">Referer</a> 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.15</a>)3975 </p> 3976 <p id="rfc.section.C.p.1 6">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.59"><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.17</a>)3977 </p> 3978 <p id="rfc.section.C.p.1 7">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>)3979 </p> 3980 <p id="rfc.section.C.p.1 8">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 5.4.1</a>)3981 </p> 3982 <p id="rfc.section.C.p. 19">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition3974 <p id="rfc.section.C.p.15">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> 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.14</a>) 3975 </p> 3976 <p id="rfc.section.C.p.16">Allow <a href="#header.referer" class="smpl">Referer</a> 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.15</a>) 3977 </p> 3978 <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.59"><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.17</a>) 3979 </p> 3980 <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>) 3981 </p> 3982 <p id="rfc.section.C.p.19">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 5.4.1</a>) 3983 </p> 3984 <p id="rfc.section.C.p.20">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition 3983 3985 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 5.5.1</a>) 3984 3986 </p> 3985 <p id="rfc.section.C.p.2 0">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3986 </p> 3987 <p id="rfc.section.C.p.2 1">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,3987 <p id="rfc.section.C.p.21">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3988 </p> 3989 <p id="rfc.section.C.p.22">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses, 3988 3990 and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>) 3989 3991 </p> 3990 <p id="rfc.section.C.p.2 2">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9.2</a>)3991 </p> 3992 <p id="rfc.section.C.p.2 3">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,3992 <p id="rfc.section.C.p.23">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 9.2</a>) 3993 </p> 3994 <p id="rfc.section.C.p.24">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields, 3993 3995 and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 9.8</a>) 3994 3996 </p> 3995 <p id="rfc.section.C.p.2 4">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>)3996 </p> 3997 <p id="rfc.section.C.p.2 5">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix B</a>)3997 <p id="rfc.section.C.p.25">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) 3998 </p> 3999 <p id="rfc.section.C.p.26">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix B</a>) 3998 4000 </p> 3999 4001 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 4713 4715 </li> 4714 4716 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/364">http://tools.ietf.org/wg/httpbis/trac/ticket/364</a>>: "Capturing more information in the method registry" 4717 </li> 4718 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 4715 4719 </li> 4716 4720 </ul>
Note: See TracChangeset
for help on using the changeset viewer.