Changeset 2018 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 29/11/12 02:03:06 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2001 r2018 449 449 } 450 450 @bottom-center { 451 content: "Expires May 31, 2013";451 content: "Expires June 2, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <link href="p1-messaging.html" rel="prev"> 492 492 <link href="p4-conditional.html" rel="next"> 493 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 8.9from Saxonica http://www.saxonica.com/">493 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.588, 2012-08-25 12:28:24, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/"> 494 494 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 495 495 <meta name="dct.creator" content="Fielding, R."> 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-11-2 7">498 <meta name="dct.issued" scheme="ISO8601" content="2012-11-29"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <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."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">November 2 7, 2012</td>526 <td class="right">November 29, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: May 31, 2013</td>529 <td class="left">Expires: June 2, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on May 31, 2013.</p>557 <p>This Internet-Draft will expire on June 2, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 4087 4087 </p> 4088 4088 <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> 4089 <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, 4090 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.1.4.2</a>) 4091 </p> 4092 <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>) 4093 </p> 4094 <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.4" title="PUT">Section 5.3.4</a>) 4095 </p> 4096 <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>) 4097 </p> 4098 <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>) 4099 </p> 4100 <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 4089 <p id="rfc.section.C.p.1"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus 4090 Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated 4091 resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4092 </p> 4093 <p id="rfc.section.C.p.2">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4094 </p> 4095 <p id="rfc.section.C.p.3">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4096 </p> 4097 <p id="rfc.section.C.p.4">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 5.3.4</a>) 4098 </p> 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 </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). 4102 (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 6.1.1</a>) 4103 </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 trailing 4101 4105 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>) 4102 4106 </p> 4103 <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>) 4104 </p> 4105 <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>) 4106 </p> 4107 <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>) 4108 </p> 4109 <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>) 4110 </p> 4111 <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 4112 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 4113 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>) 4114 </p> 4115 <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 4116 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. 4117 (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.4.5</a>) 4118 </p> 4119 <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>) 4120 </p> 4121 <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 4122 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.2</a>) 4123 </p> 4124 <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 4125 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>) 4126 </p> 4127 <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 4128 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>) 4129 </p> 4130 <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) 4131 </p> 4132 <p id="rfc.section.C.p.18">Remove the default charset of "ISO-8859-1" for text media types; the default now is whatever the media type definition says. 4133 (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4134 </p> 4135 <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 9.4</a>) 4136 </p> 4137 <p id="rfc.section.C.p.20">Remove definition of "Content-MD5 header" field because it was inconsistently implemented with respect to partial responses, 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 4116 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 needed 4121 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 </p> 4125 <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 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 </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 4131 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4132 </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.20">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.21">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition 4138 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4139 </p> 4140 <p id="rfc.section.C.p.22">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.23">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses, 4138 4143 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). 4139 4144 </p> 4140 <p id="rfc.section.C.p.2 1">IntroduceMethod Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>)4141 </p> 4142 <p id="rfc.section.C.p.2 2">Take over the Status Code Registry, previouslydefined 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>)4143 </p> 4144 <p id="rfc.section.C.p.2 3">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>)4145 </p> 4146 <p id="rfc.section.C.p.2 4">Remove discussion of Content-Disposition header field, itis 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>)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>) 4147 4152 </p> 4148 4153 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 4343 4348 <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> 4344 4349 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">7.1</a>, <a href="#rfc.iref.73"><b>7.4.7</b></a>, <a href="#rfc.xref.status.307.2">9.2.3</a>, <a href="#rfc.xref.status.307.3">C</a></li> 4345 <li>3xx Redirection (status code class) <a href="#rfc.iref.72"><b>7.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a> </li>4350 <li>3xx Redirection (status code class) <a href="#rfc.iref.72"><b>7.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a>, <a href="#rfc.xref.status.3xx.2">C</a></li> 4346 4351 </ul> 4347 4352 </li> … … 4380 4385 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.1.2.1</a>, <a href="#rfc.xref.header.accept-encoding.2">3.4.1</a>, <a href="#rfc.xref.header.accept-encoding.3">6.3</a>, <a href="#rfc.iref.a.3"><b>6.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li> 4381 4386 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.4.1</a>, <a href="#rfc.xref.header.accept-language.2">6.3</a>, <a href="#rfc.iref.a.4"><b>6.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li> 4382 <li>Allow header field <a href="#rfc.xref.header.allow.1">5.1</a>, <a href="#rfc.xref.header.allow.2">8.4</a>, <a href="#rfc.iref.a.5"><b>8.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a> </li>4387 <li>Allow header field <a href="#rfc.xref.header.allow.1">5.1</a>, <a href="#rfc.xref.header.allow.2">8.4</a>, <a href="#rfc.iref.a.5"><b>8.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a>, <a href="#rfc.xref.header.allow.5">C</a></li> 4383 4388 </ul> 4384 4389 </li> … … 4582 4587 <li>payload <a href="#rfc.iref.p.1">3.3</a></li> 4583 4588 <li>POST method <a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">5.1</a>, <a href="#rfc.iref.p.2"><b>5.3.3</b></a>, <a href="#rfc.xref.POST.3">9.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li> 4584 <li>PUT method <a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">5.1</a>, <a href="#rfc.iref.p.3"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a> </li>4589 <li>PUT method <a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">5.1</a>, <a href="#rfc.iref.p.3"><b>5.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a>, <a href="#rfc.xref.PUT.5">C</a></li> 4585 4590 </ul> 4586 4591 </li> … … 4684 4689 <li>1xx Informational <a href="#rfc.iref.s.2"><b>7.2</b></a></li> 4685 4690 <li>2xx Successful <a href="#rfc.iref.s.3"><b>7.3</b></a></li> 4686 <li>3xx Redirection <a href="#rfc.iref.s.4"><b>7.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a> </li>4691 <li>3xx Redirection <a href="#rfc.iref.s.4"><b>7.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a>, <a href="#rfc.xref.status.3xx.2">C</a></li> 4687 4692 <li>4xx Client Error <a href="#rfc.iref.s.5"><b>7.5</b></a></li> 4688 4693 <li>5xx Server Error <a href="#rfc.iref.s.6"><b>7.6</b></a></li>
Note: See TracChangeset
for help on using the changeset viewer.