Changeset 2024 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 29/11/12 23:51:24 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2023 r2024 449 449 } 450 450 @bottom-center { 451 content: "Expires June 2, 2013";451 content: "Expires June 3, 2013"; 452 452 } 453 453 @bottom-right { … … 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- 29">498 <meta name="dct.issued" scheme="ISO8601" content="2012-11-30"> 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 29, 2012</td>526 <td class="right">November 30, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 2, 2013</td>529 <td class="left">Expires: June 3, 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 June 2, 2013.</p>557 <p>This Internet-Draft will expire on June 3, 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"> <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 4089 <p id="rfc.section.C.p.1">The term "representation" is introduced, replacing both "entity" and "variant."</p> 4090 <p id="rfc.section.C.p.2"> <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 4091 Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated 4091 4092 resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4092 4093 </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 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). 4094 <p id="rfc.section.C.p.3">Rules for identifying the payload of a message have been defined. (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>) 4095 </p> 4096 <p id="rfc.section.C.p.4">GET requests can have a body; it just has no meaning. (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section 5.3.1</a>) 4097 </p> 4098 <p id="rfc.section.C.p.5">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4099 </p> 4100 <p id="rfc.section.C.p.6">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>) 4101 </p> 4102 <p id="rfc.section.C.p.7">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>) 4103 </p> 4104 <p id="rfc.section.C.p.8">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>) 4105 </p> 4106 <p id="rfc.section.C.p.9">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>) 4107 </p> 4108 <p id="rfc.section.C.p.10">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>) 4109 </p> 4110 <p id="rfc.section.C.p.11">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). 4106 4111 (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 6.1.1</a>) 4107 4112 </p> 4108 <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 trailing4113 <p id="rfc.section.C.p.12">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 4109 4114 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>) 4110 4115 </p> 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 <p id="rfc.section.C.p.13">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>) 4117 </p> 4118 <p id="rfc.section.C.p.14">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section 8.1.1.2</a>) 4119 </p> 4120 <p id="rfc.section.C.p.15">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>) 4121 </p> 4122 <p id="rfc.section.C.p.16">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). 4123 </p> 4124 <p id="rfc.section.C.p.17">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>) 4125 </p> 4126 <p id="rfc.section.C.p.18">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>) 4127 </p> 4128 <p id="rfc.section.C.p.19">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4122 4129 based upon the request method semantics. (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section 7.4</a>) 4123 4130 </p> 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 clarifications4131 <p id="rfc.section.C.p.20">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 4125 4132 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>) 4126 4133 </p> 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 needed4134 <p id="rfc.section.C.p.21">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>) 4135 </p> 4136 <p id="rfc.section.C.p.22">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>) 4137 </p> 4138 <p id="rfc.section.C.p.23">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 4139 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 4140 </p> 4134 <p id="rfc.section.C.p.2 0">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.2 1">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.2 2">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.2 3"> <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.2 4">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always4141 <p id="rfc.section.C.p.24">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>) 4142 </p> 4143 <p id="rfc.section.C.p.25">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>) 4144 </p> 4145 <p id="rfc.section.C.p.26">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>) 4146 </p> 4147 <p id="rfc.section.C.p.27"> <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>) 4148 </p> 4149 <p id="rfc.section.C.p.28">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always 4143 4150 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4144 4151 </p> 4145 <p id="rfc.section.C.p.2 5">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 definition4152 <p id="rfc.section.C.p.29">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>) 4153 </p> 4154 <p id="rfc.section.C.p.30">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) 4155 </p> 4156 <p id="rfc.section.C.p.31">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition 4150 4157 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4151 4158 </p> 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,4159 <p id="rfc.section.C.p.32">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>) 4160 </p> 4161 <p id="rfc.section.C.p.33">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses, 4155 4162 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). 4156 4163 </p> 4157 <p id="rfc.section.C.p.3 0">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.3 1">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.3 2">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.3 3">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>)4164 <p id="rfc.section.C.p.34">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>) 4165 </p> 4166 <p id="rfc.section.C.p.35">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>) 4167 </p> 4168 <p id="rfc.section.C.p.36">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>) 4169 </p> 4170 <p id="rfc.section.C.p.37">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>) 4164 4171 </p> 4165 4172 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 4414 4421 </li> 4415 4422 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 4416 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">8.1</a>, <a href="#rfc.iref.d.3"><b>8.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a> </li>4423 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">8.1</a>, <a href="#rfc.iref.d.3"><b>8.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a>, <a href="#rfc.xref.header.date.4">C</a></li> 4417 4424 <li>deflate (content coding) <a href="#rfc.iref.d.1"><b>3.1.2.1</b></a></li> 4418 4425 <li>DELETE method <a href="#rfc.xref.DELETE.1">5.1</a>, <a href="#rfc.iref.d.2"><b>5.3.5</b></a>, <a href="#rfc.xref.DELETE.2">9.1.3</a></li> … … 4433 4440 </li> 4434 4441 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 4435 <li>GET method <a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.g.18"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a> </li>4442 <li>GET method <a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.g.18"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a>, <a href="#rfc.xref.GET.4">C</a></li> 4436 4443 <li><tt>Grammar</tt> 4437 4444 <ul>
Note: See TracChangeset
for help on using the changeset viewer.