Changeset 2023
- Timestamp:
- 29/11/12 04:28:13 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2018 r2023 4099 4099 <p id="rfc.section.C.p.5">The CONNECT method is now defined by this specification, taking over 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>) 4100 4100 </p> 4101 <p id="rfc.section.C.p.6">The "<a href="#header.max-forwards" class="smpl">Max-Forwards</a>" header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4101 <p id="rfc.section.C.p.6">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 5.3.6</a>) 4102 </p> 4103 <p id="rfc.section.C.p.7">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 5.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section 5.3.8</a>) 4104 </p> 4105 <p id="rfc.section.C.p.8">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4102 4106 (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 6.1.1</a>) 4103 4107 </p> 4104 <p id="rfc.section.C.p. 7">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 trailing4108 <p id="rfc.section.C.p.9">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 4105 4109 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>) 4106 4110 </p> 4107 <p id="rfc.section.C.p.8">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>) 4108 </p> 4109 <p id="rfc.section.C.p.9">"<a href="#header.referer" class="smpl">Referer</a>" can now hoave a field value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>) 4110 </p> 4111 <p id="rfc.section.C.p.10">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened 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>) 4112 </p> 4113 <p id="rfc.section.C.p.11">Redirect 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> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>) 4114 </p> 4115 <p id="rfc.section.C.p.12">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4111 <p id="rfc.section.C.p.10">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>) 4112 </p> 4113 <p id="rfc.section.C.p.11">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>) 4114 </p> 4115 <p id="rfc.section.C.p.12">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one). 4116 </p> 4117 <p id="rfc.section.C.p.13">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened 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>) 4118 </p> 4119 <p id="rfc.section.C.p.14">Redirect 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> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>) 4120 </p> 4121 <p id="rfc.section.C.p.15">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4116 4122 based upon the request method semantics. (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section 7.4</a>) 4117 </p>4118 <p id="rfc.section.C.p.13">User agents are now allowed to rewrite 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>)4119 </p>4120 <p id="rfc.section.C.p.14">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed4121 to be accessed through the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The recipient 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.4.5</a>)4122 </p>4123 <p id="rfc.section.C.p.15">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been 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>)4124 4123 </p> 4125 4124 <p id="rfc.section.C.p.16">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications 4126 4125 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.2</a>) 4127 4126 </p> 4128 <p id="rfc.section.C.p.17"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>) 4129 </p> 4130 <p id="rfc.section.C.p.18">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always 4127 <p id="rfc.section.C.p.17">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 7.4.4</a>) 4128 </p> 4129 <p id="rfc.section.C.p.18">User agents are now allowed to rewrite 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>) 4130 </p> 4131 <p id="rfc.section.C.p.19">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed 4132 to be accessed through the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The recipient 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.4.5</a>) 4133 </p> 4134 <p id="rfc.section.C.p.20">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 7.5.1</a>) 4135 </p> 4136 <p id="rfc.section.C.p.21">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section 7.5.3</a>) 4137 </p> 4138 <p id="rfc.section.C.p.22">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been 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>) 4139 </p> 4140 <p id="rfc.section.C.p.23"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>) 4141 </p> 4142 <p id="rfc.section.C.p.24">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always 4131 4143 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4132 4144 </p> 4133 <p id="rfc.section.C.p. 19">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <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>)4134 </p> 4135 <p id="rfc.section.C.p.2 0">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>)4136 </p> 4137 <p id="rfc.section.C.p.2 1">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition4145 <p id="rfc.section.C.p.25">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <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>) 4146 </p> 4147 <p id="rfc.section.C.p.26">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) 4148 </p> 4149 <p id="rfc.section.C.p.27">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition 4138 4150 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4139 4151 </p> 4140 <p id="rfc.section.C.p.2 2">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>)4141 </p> 4142 <p id="rfc.section.C.p.2 3">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses,4152 <p id="rfc.section.C.p.28">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>) 4153 </p> 4154 <p id="rfc.section.C.p.29">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses, 4143 4155 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). 4144 4156 </p> 4145 <p id="rfc.section.C.p. 24">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>)4146 </p> 4147 <p id="rfc.section.C.p. 25">The Status Code Registry is now defined by this specification; previously, it was 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 9.2</a>)4148 </p> 4149 <p id="rfc.section.C.p. 26">References to the "identity" transfer-coding value token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>)4150 </p> 4151 <p id="rfc.section.C.p. 27">The Content-Disposition header field 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>)4157 <p id="rfc.section.C.p.30">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>) 4158 </p> 4159 <p id="rfc.section.C.p.31">The Status Code Registry is now defined by this specification; previously, it was 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 9.2</a>) 4160 </p> 4161 <p id="rfc.section.C.p.32">References to the "identity" transfer-coding value token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) 4162 </p> 4163 <p id="rfc.section.C.p.33">The Content-Disposition header field 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>) 4152 4164 </p> 4153 4165 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 4344 4356 <li>301 Moved Permanently (status code) <a href="#rfc.xref.status.301.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.2</b></a>, <a href="#rfc.xref.status.301.2">9.2.3</a>, <a href="#rfc.xref.status.301.3">C</a></li> 4345 4357 <li>302 Found (status code) <a href="#rfc.xref.status.302.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.3</b></a>, <a href="#rfc.xref.status.302.2">9.2.3</a>, <a href="#rfc.xref.status.302.3">C</a></li> 4346 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.4</b></a>, <a href="#rfc.xref.status.303.2">9.2.3</a> </li>4358 <li>303 See Other (status code) <a href="#rfc.xref.status.303.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.4</b></a>, <a href="#rfc.xref.status.303.2">9.2.3</a>, <a href="#rfc.xref.status.303.3">C</a></li> 4347 4359 <li>305 Use Proxy (status code) <a href="#rfc.xref.status.305.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.5</b></a>, <a href="#rfc.xref.status.305.2">9.2.3</a>, <a href="#rfc.xref.status.305.3">C</a></li> 4348 4360 <li>306 (Unused) (status code) <a href="#rfc.iref.73"><b>7.4.6</b></a>, <a href="#rfc.xref.status.306.1">9.2.3</a></li> … … 4352 4364 </li> 4353 4365 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 4354 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.1</b></a>, <a href="#rfc.xref.status.400.2">9.2.3</a> </li>4366 <li>400 Bad Request (status code) <a href="#rfc.xref.status.400.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.1</b></a>, <a href="#rfc.xref.status.400.2">9.2.3</a>, <a href="#rfc.xref.status.400.3">C</a></li> 4355 4367 <li>402 Payment Required (status code) <a href="#rfc.xref.status.402.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.2</b></a>, <a href="#rfc.xref.status.402.2">9.2.3</a></li> 4356 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.3</b></a>, <a href="#rfc.xref.status.403.2">9.2.3</a> </li>4368 <li>403 Forbidden (status code) <a href="#rfc.xref.status.403.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.3</b></a>, <a href="#rfc.xref.status.403.2">9.2.3</a>, <a href="#rfc.xref.status.403.3">C</a></li> 4357 4369 <li>404 Not Found (status code) <a href="#rfc.xref.status.404.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.4</b></a>, <a href="#rfc.xref.status.404.2">9.2.3</a></li> 4358 4370 <li>405 Method Not Allowed (status code) <a href="#rfc.xref.status.405.1">7.1</a>, <a href="#rfc.iref.74"><b>7.5.5</b></a>, <a href="#rfc.xref.status.405.2">9.2.3</a></li> … … 4391 4403 <li>cacheable <a href="#rfc.iref.c.8"><b>5.2.3</b></a></li> 4392 4404 <li>compress (content coding) <a href="#rfc.iref.c.4"><b>3.1.2.1</b></a></li> 4393 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">5.1</a>, <a href="#rfc.iref.c.9"><b>5.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">9.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a> </li>4405 <li>CONNECT method <a href="#rfc.xref.CONNECT.1">5.1</a>, <a href="#rfc.iref.c.9"><b>5.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">9.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a>, <a href="#rfc.xref.CONNECT.4">C</a></li> 4394 4406 <li>content coding <a href="#rfc.iref.c.3"><b>3.1.2.1</b></a></li> 4395 4407 <li>content negotiation <a href="#rfc.iref.c.1">1</a></li> … … 4507 4519 </li> 4508 4520 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 4509 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">5.1</a>, <a href="#rfc.iref.o.1"><b>5.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">6.1.1</a>, <a href="#rfc.xref.OPTIONS.3">9.1.3</a> </li>4521 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">5.1</a>, <a href="#rfc.iref.o.1"><b>5.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">6.1.1</a>, <a href="#rfc.xref.OPTIONS.3">9.1.3</a>, <a href="#rfc.extref.o.13">C</a>, <a href="#rfc.xref.OPTIONS.4">C</a></li> 4510 4522 </ul> 4511 4523 </li> … … 4698 4710 </li> 4699 4711 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 4700 <li>TRACE method <a href="#rfc.xref.TRACE.1">5.1</a>, <a href="#rfc.iref.t.1"><b>5.3.8</b></a>, <a href="#rfc.xref.TRACE.2">6.1.1</a>, <a href="#rfc.xref.TRACE.3">9.1.3</a>, <a href="#rfc.xref.TRACE.4">10.1</a> </li>4712 <li>TRACE method <a href="#rfc.xref.TRACE.1">5.1</a>, <a href="#rfc.iref.t.1"><b>5.3.8</b></a>, <a href="#rfc.xref.TRACE.2">6.1.1</a>, <a href="#rfc.xref.TRACE.3">9.1.3</a>, <a href="#rfc.xref.TRACE.4">10.1</a>, <a href="#rfc.extref.t.23">C</a>, <a href="#rfc.xref.TRACE.5">C</a></li> 4701 4713 </ul> 4702 4714 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2013 r2023 5678 5678 </t> 5679 5679 <t> 5680 The "<x:ref>Max-Forwards</x:ref>" header field is now restricted to the 5680 The requirements upon and semantics of CONNECT request and response bodies 5681 have been clarified. 5682 (<xref target="CONNECT"/>) 5683 </t> 5684 <t> 5685 The <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> request methods are 5686 now defined as being safe. 5687 (<xref target="OPTIONS"/> and <xref target="TRACE"/>) 5688 </t> 5689 <t> 5690 The <x:ref>Max-Forwards</x:ref> header field is now restricted to the 5681 5691 OPTIONS and TRACE methods (previously, extension methods could have used it 5682 5692 as well). … … 5696 5706 </t> 5697 5707 <t> 5698 "<x:ref>Referer</x:ref>" can now hoave a field value of "about:blank" as an5699 alternative to not sending a Referer header field.5708 The <x:ref>Referer</x:ref> header field can now have a value of 5709 "about:blank" as an alternative to not sending a Referer header field. 5700 5710 (<xref target="header.referer"/>) 5711 </t> 5712 <t> 5713 The <x:ref>201 (Created)</x:ref> status code can indicate that more than 5714 one resource has been created (as well as just one). 5701 5715 </t> 5702 5716 <t> … … 5716 5730 based upon the request method semantics. 5717 5731 (<xref target="status.3xx"/>) 5732 </t> 5733 <t> 5734 The syntax of the <x:ref>Location</x:ref> header field has been corrected 5735 to allow URI references (including relative references and fragments), along 5736 with some clarifications as to when use of fragments would not be 5737 appropriate. 5738 (<xref target="header.location"/>) 5739 </t> 5740 <t> 5741 The 303 (See Other) status code is now cacheable, if explicit freshness 5742 information is available. 5743 (<xref target="status.303" />) 5718 5744 </t> 5719 5745 <t> … … 5733 5759 </t> 5734 5760 <t> 5761 The <x:ref>400 (Bad Request)</x:ref> status code has been made more generic; 5762 it isn't limited to syntax errors. 5763 (<xref target="status.400"/>) 5764 </t> 5765 <t> 5766 The <x:ref>403 (Forbidden)</x:ref> status code has been clarified, 5767 especially with regards to authentication. 5768 (<xref target="status.403"/>) 5769 </t> 5770 <t> 5735 5771 The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated 5736 5772 from <xref target="RFC2817"/>. 5737 5773 (<xref target="status.426"/>) 5738 </t>5739 <t>5740 The syntax of the <x:ref>Location</x:ref> header field has been corrected5741 to allow URI references (including relative references and fragments), along5742 with some clarifications as to when use of fragments would not be5743 appropriate.5744 (<xref target="header.location"/>)5745 5774 </t> 5746 5775 <t>
Note: See TracChangeset
for help on using the changeset viewer.