Source: https://trac.ietf.org/trac/httpbis/changeset/2391/draft-ietf-httpbis
Timestamp: 2020-07-08 02:44:06
Document Index: 452729561

Matched Legal Cases: ['art2', 'art2', 'art2', 'art6', 'art6', 'art6', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2']

Changeset 2391 for draft-ietf-httpbis – Hypertext Transfer Protocol Wiki
Changeset 2391 for draft-ietf-httpbis
14/09/13 05:57:34 (7 years ago)
content: "Expires March 10, 2014";
<meta name="dct.issued" scheme="ISO8601" content="2013-09-06">
<td class="right">September 6, 2013</td>
<td class="left">Expires: March 10, 2014</td>
<p>This Internet-Draft will expire on March 10, 2014.</p>
a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for status and warning codes related to transformations.
<p id="rfc.section.3.3.1.p.8">A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Transfer-Encoding header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
<p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a>.
anticipate such a body.
<p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
<p id="rfc.section.3.3.2.p.7">A server <em class="bcp14">MAY</em> send a Content-Length header field in a response to a HEAD request (<a href="p2-semantics.html#HEAD" title="HEAD">Section 4.3.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>); a server <em class="bcp14">MUST NOT</em> send Content-Length in such a response unless its field-value equals the decimal number of octets that would have been sent
<p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">SHOULD NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;
are defined in <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side
<p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,
<p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
<p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.
methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.
<p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.
<p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
<p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless
purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
<p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
<li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">8.4.1</a>, <a href="#rfc.xref.Part2.30">9.3</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
<li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">3.3.2</a></li>
<li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.29">8.4.1</a></li>
<li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
<li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.3</a></li>
<li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">4.3</a></li>
<li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">6.3.2</a></li>
<li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.27">6.3.2</a></li>
<li><em>Section 4.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.16">3.3.2</a></li>
<li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.20">5.3</a></li>
<li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.3</a></li>
<li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">4.3</a></li>
<li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.6</a></li>
<li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.24">5.7.2</a></li>
<li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.7</a></li>
<li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">9.3</a></li>
<li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.30">9.3</a></li>
A server &MUST-NOT; send a Transfer-Encoding header field in any response
with a status code of
<x:ref>1xx (Informational)</x:ref> or <x:ref>204 (No Content)</x:ref>.
A server &MUST-NOT; send a Transfer-Encoding header field in any
<x:ref>2xx (Successful)</x:ref> response to a CONNECT request (&CONNECT;).
Transfer-Encoding was added in HTTP/1.1. It is generally assumed that
implementations advertising only HTTP/1.0 support will not understand
A server &SHOULD-NOT; send a Content-Length header field in any
A server &MUST-NOT; send a Content-Length header field in any
<p id="rfc.section.4.3.6.p.10">A server <em class="bcp14">SHOULD NOT</em> send any <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a> or <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header fields in a successful response to CONNECT. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
<x:ref>Content-Length</x:ref> header fields in a successful response
A server &MUST-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
<x:ref>Content-Length</x:ref> header fields in a
<x:ref>2xx (Successful)</x:ref> response to CONNECT.
fields received in a successful response to CONNECT.