Changeset 2400
- Timestamp:
- 15/09/13 00:57:24 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2398 r2400 1017 1017 </p> 1018 1018 <p id="rfc.section.2.6.p.10">A client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after 1019 the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.1019 the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions. 1020 1020 </p> 1021 1021 <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than … … 1194 1194 </div> 1195 1195 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1196 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1196 </pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1197 1197 </p> 1198 1198 <div id="rfc.iref.r.6"></div> … … 3015 3015 </p> 3016 3016 <p id="rfc.section.A.2.p.15">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. 3017 The asterisk-form of the request-target is only allowed inthe OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>)3017 The asterisk-form of the request-target is only allowed with the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>) 3018 3018 </p> 3019 3019 <p id="rfc.section.A.2.p.16">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>) -
draft-ietf-httpbis/latest/p1-messaging.xml
r2398 r2400 758 758 the server incorrectly implements the HTTP specification, but only 759 759 after the client has attempted at least one normal request and determined 760 from the response status or header fields (e.g., <x:ref>Server</x:ref>) that760 from the response status code or header fields (e.g., <x:ref>Server</x:ref>) that 761 761 the server improperly handles higher request versions. 762 762 </t> … … 1124 1124 </artwork></figure> 1125 1125 <t> 1126 The methods defined by this specification can be found in1126 The request methods defined by this specification can be found in 1127 1127 &methods;, along with information regarding the HTTP method registry 1128 1128 and considerations for defining new methods. … … 5121 5121 The segment + query components of RFC 3986 have been used to define the 5122 5122 request-target, instead of abs_path from RFC 1808. 5123 The asterisk-form of the request-target is only allowed inthe OPTIONS5123 The asterisk-form of the request-target is only allowed with the OPTIONS 5124 5124 method. 5125 5125 (<xref target="request-target"/>) -
draft-ietf-httpbis/latest/p2-semantics.html
r2398 r2400 1740 1740 <div id="rfc.iref.m.1"></div> 1741 1741 <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3> 1742 <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting1743 to trace a request that appears to be failing or looping mid-chain.1742 <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client 1743 is attempting to trace a request that appears to be failing or looping mid-chain. 1744 1744 </p> 1745 1745 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> … … 2420 2420 servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 2421 2421 </p> 2422 <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx status responses received prior to a final response, even if the client does not expect one.2423 A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx statusresponses.2422 <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user 2423 agent <em class="bcp14">MAY</em> ignore unexpected 1xx responses. 2424 2424 </p> 2425 2425 <p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an … … 2688 2688 <div id="rfc.iref.71"></div> 2689 2689 <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a> <a id="status.404" href="#status.404">404 Not Found</a></h3> 2690 <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status does not indicate whether this lack of representation is temporary2691 or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition2690 <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is 2691 temporary or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition 2692 2692 is likely to be permanent. 2693 2693 </p> … … 2696 2696 <div id="rfc.iref.71"></div> 2697 2697 <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a> <a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 2698 <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.2698 <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method received in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods. 2699 2699 </p> 2700 2700 <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). … … 2761 2761 <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a> <a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3> 2762 2762 <p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported 2763 by th e <a href="#resources" class="smpl">target resource</a> for this method. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.2763 by this method on the <a href="#resources" class="smpl">target resource</a>. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly. 2764 2764 </p> 2765 2765 <div id="rfc.iref.71"></div> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2398 r2400 1968 1968 The "Max-Forwards" header field provides a mechanism with the 1969 1969 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 1970 methods to limit the number of times that the request is forwarded by1970 request methods to limit the number of times that the request is forwarded by 1971 1971 proxies. This can be useful when the client is attempting to 1972 1972 trace a request that appears to be failing or looping mid-chain. … … 2729 2729 </t> 2730 2730 <t> 2731 A client &MUST; be able to parse one or more 1xx statusresponses received2731 A client &MUST; be able to parse one or more 1xx responses received 2732 2732 prior to a final response, even if the client does not expect one. 2733 A user agent &MAY; ignore unexpected 1xx statusresponses.2733 A user agent &MAY; ignore unexpected 1xx responses. 2734 2734 </t> 2735 2735 <t> … … 3322 3322 server did not find a current representation for the 3323 3323 <x:ref>target resource</x:ref> or is not willing to disclose that one 3324 exists. A 404 status does not indicate whether this lack of representation3324 exists. A 404 status code does not indicate whether this lack of representation 3325 3325 is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is 3326 3326 preferred over 404 if the origin server knows, presumably through some … … 3338 3338 <t> 3339 3339 The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the 3340 method specified in the request-line is known by the origin server but3340 method received in the request-line is known by the origin server but 3341 3341 not supported by the <x:ref>target resource</x:ref>. 3342 3342 The origin server &MUST; generate an <x:ref>Allow</x:ref> header field in … … 3494 3494 The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that 3495 3495 the origin server is refusing to service the request because the payload is 3496 in a format not supported by th e <x:ref>target resource</x:ref> for this3497 method.The format problem might be due to the request's indicated3496 in a format not supported by this method on the <x:ref>target resource</x:ref>. 3497 The format problem might be due to the request's indicated 3498 3498 <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a 3499 3499 result of inspecting the data directly. -
draft-ietf-httpbis/latest/p6-cache.html
r2397 r2400 779 779 </p> 780 780 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2> 781 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 782 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 781 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 783 782 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields. 784 783 </p> … … 1155 1154 to keep their contents up-to-date. 1156 1155 </p> 1157 <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.1156 <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error status code is received in response to an unsafe request method. 1158 1157 </p> 1159 1158 <p id="rfc.section.4.4.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks. -
draft-ietf-httpbis/latest/p6-cache.xml
r2397 r2400 322 322 A response message is considered complete when all of the octets indicated 323 323 by the message framing (&messaging;) are received prior to the connection 324 being closed. If the request is GET, the response status is <x:ref>200325 (OK)</x:ref>, and the entire response header block has been received, a324 being closed. If the request method is GET, the response status code is 325 <x:ref>200 (OK)</x:ref>, and the entire response header block has been received, a 326 326 cache &MAY; store an incomplete response message body if the cache entry is 327 327 recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref> … … 1113 1113 (&effective-request-uri;) as well as the URI(s) in the 1114 1114 <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header 1115 fields (if present) when a non-error response to a request with an unsafe1116 method is received.1115 fields (if present) when a non-error status code is received in response to 1116 an unsafe request method. 1117 1117 </t> 1118 1118 <t>
Note: See TracChangeset
for help on using the changeset viewer.