Changeset 1891 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 13/09/12 11:44:49 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1890 r1891 449 449 } 450 450 @bottom-center { 451 content: "Expires March 1 6, 2013";451 content: "Expires March 17, 2013"; 452 452 } 453 453 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-09-1 2">500 <meta name="dct.issued" scheme="ISO8601" content="2012-09-13"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 529 529 </tr> 530 530 <tr> 531 <td class="left">Expires: March 1 6, 2013</td>531 <td class="left">Expires: March 17, 2013</td> 532 532 <td class="right">greenbytes</td> 533 533 </tr> 534 534 <tr> 535 535 <td class="left"></td> 536 <td class="right">September 1 2, 2012</td>536 <td class="right">September 13, 2012</td> 537 537 </tr> 538 538 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on March 1 6, 2013.</p>563 <p>This Internet-Draft will expire on March 17, 2013.</p> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 4215 4215 </p> 4216 4216 <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> 4217 <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 10.1</a>) 4217 <p id="rfc.section.C.p.1">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, 4218 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 3.2.4</a>) 4218 4219 </p> 4219 4220 <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) … … 4223 4224 <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.3" title="CONNECT">Section 5.3.6</a>) 4224 4225 </p> 4225 <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 10.2</a>) 4226 </p> 4227 <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 7.3.4</a>) 4228 </p> 4229 <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 7.4</a>) 4230 </p> 4231 <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 4226 <p id="rfc.section.C.p.5">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 6.1.1</a>) 4227 </p> 4228 <p id="rfc.section.C.p.6">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 4229 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 6.1.2</a>) 4230 </p> 4231 <p id="rfc.section.C.p.7">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 6.3.3</a>) 4232 </p> 4233 <p id="rfc.section.C.p.8">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 6.5.2</a>) 4234 </p> 4235 <p id="rfc.section.C.p.9">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 7.3.4</a>) 4236 </p> 4237 <p id="rfc.section.C.p.10">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 7.4</a>) 4238 </p> 4239 <p id="rfc.section.C.p.11">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the 4232 4240 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 4233 4241 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">7.4.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.4.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.4.7</a>) 4234 4242 </p> 4235 <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 through4243 <p id="rfc.section.C.p.12">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 4236 4244 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. 4237 4245 (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.4.5</a>) 4238 4246 </p> 4239 <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 7.5.15</a>) 4240 </p> 4241 <p id="rfc.section.C.p.11">Change ABNF productions for header fields to only define the field value.</p> 4242 <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 4247 <p id="rfc.section.C.p.13">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><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.5.15</a>) 4248 </p> 4249 <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 4250 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 8.1.1</a>) 4251 </p> 4252 <p id="rfc.section.C.p.15">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 4243 4253 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 8.4.1</a>) 4244 4254 </p> 4245 <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 4246 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 6.1.2</a>) 4247 </p> 4248 <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 4249 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 8.1.1</a>) 4250 </p> 4251 <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 6.1.1</a>) 4252 </p> 4253 <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 6.5.2</a>) 4254 </p> 4255 <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 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4256 </p> 4257 <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 9.3</a>) 4255 <p id="rfc.section.C.p.16">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 4256 in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4257 </p> 4258 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 9.3</a>) 4259 </p> 4260 <p id="rfc.section.C.p.18">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition 4261 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 9.5.1</a>) 4258 4262 </p> 4259 4263 <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 10.4</a>) 4260 4264 </p> 4261 <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 4262 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 9.5.1</a>) 4263 </p> 4264 <p id="rfc.section.C.p.21">Change ABNF productions for header fields to only define the field value.</p> 4265 <p id="rfc.section.C.p.22">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses, 4265 <p id="rfc.section.C.p.20">Remove definition of "Content-MD5 header" field because it was inconsistently implemented with respect to partial responses, 4266 4266 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). 4267 4267 </p> 4268 <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 6.3.3</a>) 4269 </p> 4270 <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, 4271 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 3.2.4</a>) 4272 </p> 4273 <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>) 4274 </p> 4275 <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>) 4268 <p id="rfc.section.C.p.21">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section 10.1</a>) 4269 </p> 4270 <p id="rfc.section.C.p.22">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.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 10.2</a>) 4271 </p> 4272 <p id="rfc.section.C.p.23">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>) 4273 </p> 4274 <p id="rfc.section.C.p.24">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>) 4276 4275 </p> 4277 4276 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 5387 5386 </li> 5388 5387 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">C</a>, <a href="#rfc.xref.RFC2817.3">C</a>, <a href="#rfc.xref.RFC2817.4">C</a><ul> 5389 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#rfc.xref.RFC2817. 3">C</a></li>5388 <li><em>Section 7.1</em> <a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#rfc.xref.RFC2817.4">C</a></li> 5390 5389 </ul> 5391 5390 </li>
Note: See TracChangeset
for help on using the changeset viewer.