Source: https://trac.ietf.org/trac/httpbis/changeset/1741/draft-ietf-httpbis
Timestamp: 2020-05-29 13:55:35
Document Index: 328956740

Matched Legal Cases: ['art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1']

Changeset 1741 for draft-ietf-httpbis – Hypertext Transfer Protocol Wiki
Changeset 1741 for draft-ietf-httpbis
p1-messaging.xml (modified) (42 diffs)
(<xref target="header.via"/>) header fields for both connections.
defined for all versions of HTTP/1.x. In particular, the <x:ref>Host</x:ref>
and <x:ref>Connection</x:ref> header fields ought to be implemented by all
HTTP/1.x implementations whether or not they advertise conformance with
the message's HTTP version. An unrecognized header field received
by a proxy &MUST; be forwarded downstream unless the header field's
field-name is listed in the message's Connection header field
field-name is listed in the message's <x:ref>Connection</x:ref> header field
a Content-Length or Transfer-Encoding header field.
Request message framing is independent of method semantics,
a <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
status code (<xref target="status-code"/>).
Responses to the HEAD request method never include a message body
because the associated response header fields (e.g.,
<x:ref>Transfer-Encoding</x:ref>, <x:ref>Content-Length</x:ref>, etc.) only
indicate what their values would have been if the request method had been
GET. <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel
mode instead of having a message body.
When a message does not have a Transfer-Encoding header field and the
payload body length can be determined prior to being transferred, a
When a message does not have a <x:ref>Transfer-Encoding</x:ref> header field
and the payload body length can be determined prior to being transferred, a
payload body that is either present as the message body, for requests
or Transfer-Encoding header fields received in such a message.
concludes the header fields. A client &MUST; ignore any
<x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref> header
fields received in such a message.
If a Transfer-Encoding header field is present in a response and the
length is determined by reading the connection until it is closed by
If a message is received without <x:ref>Transfer-Encoding</x:ref> and with
either multiple <x:ref>Content-Length</x:ref> header fields having
differing field-values or a single Content-Length header field having an
invalid value, then the message framing is invalid and &MUST; be treated
as an error to prevent request or response smuggling.
If a valid <x:ref>Content-Length</x:ref> header field is present without
<x:ref>Transfer-Encoding</x:ref>, its decimal value defines the
message body length in octets. If the actual number of octets sent in
the message is less than the indicated Content-Length, the recipient
not a <x:ref>Content-Length</x:ref> by responding with
<x:ref>411 (Length Required)</x:ref>.
valid Content-Length header field if it does not know the server will
handle HTTP/1.1 (or later) requests; such knowledge can be in the form
of specific user configuration or by remembering the version of a prior
the form of specific user configuration or by remembering the version of a
prior received response.
been received. A message that uses a valid Content-Length is incomplete
if the size of the message body received (in octets) is less than the
fields at the end of the message. The <x:ref>Trailer</x:ref> header field
can be used to indicate which header fields are included in a trailer (see
Therefore, the keyword &MUST; be supplied within a <x:ref>Connection</x:ref>
header field (<xref target="header.connection"/>) whenever TE is present in
an HTTP/1.1 message.
Both transfer codings (TE request header field, <xref target="header.te"/>)
Both transfer codings (<x:ref>TE</x:ref> request header field,
<xref target="header.te"/>) and content negotiation (&content.negotiation;)
use short "floating point" numbers to indicate the relative importance
("weight") of various negotiable parameters. A weight is normalized to a
real number in the range 0 through 1, where 0 is the minimum and 1 the
maximum value. If a parameter has a quality value of 0, then content with
<t><x:ref>Transfer-Encoding</x:ref></t>
<t><x:ref>Content-Length</x:ref></t>
<t><x:ref>Trailer</x:ref></t>
A Host header field is also sent, as defined in
<xref target="header.host"/>, containing the target URI's
authority component (excluding any userinfo).
host name configured for the server, a colon (":"), and the connection's
Intermediaries that forward a message &MUST; implement the
Connection header field as specified in <xref target="header.connection"/>.
<x:ref>Connection</x:ref> header field as specified in
<xref target="header.connection"/>.
<t><x:ref>Connection</x:ref></t>
<t>Keep-Alive (<xref target="RFC2068" x:fmt="of" x:sec="19.7.1.1"/>)</t>
<t><x:ref>Proxy-Authenticate</x:ref> (&header-proxy-authenticate;)</t>
<t><x:ref>Proxy-Authorization</x:ref> (&header-proxy-authorization;)</t>
<t><x:ref>TE</x:ref></t>
<t><x:ref>Upgrade</x:ref></t>
Other hop-by-hop header fields &MUST; be listed in a Connection header field
Other hop-by-hop header fields &MUST; be listed in a
<x:ref>Connection</x:ref> header field (<xref target="header.connection"/>).
field including the connection option "close" was sent in the request. If
the server chooses to close the connection immediately after sending the
"close". In case the client does not want to maintain a connection for more
<x:ref>Connection</x:ref> header field, that request becomes the last one
tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header
field. Each registered protocol name is associated with contact information
and an optional set of specifications that details how the connection
<x:source href="p7-auth.xml" basename="p7-auth">
<x:defines>Proxy-Authenticate</x:defines>
<x:defines>Proxy-Authorization</x:defines>
hosts (selection of resource by inspection of the Host header
<section title="Multi-homed Web Servers" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
The requirements that clients and servers support the Host header
field (<xref target="header.host"/>), report an error if it is
The requirements that clients and servers support the <x:ref>Host</x:ref>
header field (<xref target="header.host"/>), report an error if it is
are among the most important changes defined by HTTP/1.1.
to which that request was directed. The Host header field was
to which that request was directed. The <x:ref>Host</x:ref> header field was
introduced during the development of HTTP/1.1 and, though it was
quickly implemented by most HTTP/1.0 browsers, additional requirements
Require recipients to handle bogus <x:ref>Content-Length</x:ref> header
fields as errors.
Define the semantics of the <x:ref>Upgrade</x:ref> header field in responses
other than 101 (this was incorporated from <xref target="RFC2817"/>).
<p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
<p id="rfc.section.2.3.1.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;9.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
<p id="rfc.section.2.3.8.p.5">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. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response.
<p id="rfc.section.2.3.8.p.6">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains
<p id="rfc.section.2.3.8.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p>
</pre><p id="rfc.section.2.3.8.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
</pre><p id="rfc.section.2.3.8.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
<p id="rfc.section.2.3.8.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
<p id="rfc.section.2.3.8.p.11">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
<p id="rfc.section.2.3.8.p.12">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to
<p id="rfc.section.2.3.8.p.13">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
<p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
<p id="rfc.section.4.6.10.p.1">The server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
<p id="rfc.section.6.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure
<p id="rfc.section.7.p.4">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
</pre><p id="rfc.section.9.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
<p id="rfc.section.11.1.p.4">The <a href="#header.referer" class="smpl">Referer</a> header field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can
<p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
response &MUST; include a <x:ref>Content-Length</x:ref> field with a
field-value of "0".
information. The value of the <x:ref>Via</x:ref> header field (&header-via;)
is of particular interest, since it acts as a trace of the request chain.
Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
limit the length of the request chain, which is useful for testing a chain of
A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length
A server &SHOULD-NOT; send any <x:ref>Transfer-Encoding</x:ref> or
<x:ref>Content-Length</x:ref> header fields in a successful response.
A client &MUST; ignore any Content-Length or Transfer-Encoding header
<x:lt><t>Whether it is appropriate to list the field-name in the
<x:ref>Connection</x:ref> header field (i.e., if the header field is to
be hop-by-hop, see &header-connection;).</t></x:lt>
<x:anchor-alias value="101 (Switching Protocols)"/>
The server understands and is willing to comply with the client's request,
via the <x:ref>Upgrade</x:ref> message header field (&header-upgrade;), for
server will switch protocols to those defined by the response's Upgrade
header field immediately after the empty line which terminates the 101
The server refuses to accept the request without a defined
<x:ref>Content-Length</x:ref>. The client &MAY; repeat the request if it
adds a valid Content-Length header field containing the length of the
message body in the request message.
response &MUST; include an <x:ref>Upgrade</x:ref> header field
(&header-upgrade;) specifying the required protocols.
from the message body by decoding any <x:ref>Transfer-Encoding</x:ref> that
might have been applied to ensure safe and proper transfer of the message.
If the response is being forwarded through a proxy, the proxy application
&MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
&MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
&SHOULD; remove, or replace with sanitized versions, any <x:ref>Via</x:ref>
fields generated behind the firewall.
<x:defines>Via</x:defines>
(&header-transfer-encoding;). Proxies/gateways &MUST; remove any
transfer-coding prior to forwarding a message via a MIME-compliant protocol.
</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
<p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
<p id="rfc.section.2.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules:
unless the cache is confident in the value of the <x:ref>Age</x:ref> header
field (e.g., because there are no HTTP/1.0 hops in the Via header field), in
which case the corrected_age_value &MAY; be used as the
field (e.g., because there are no HTTP/1.0 hops in the <x:ref>Via</x:ref>
header field), in which case the corrected_age_value &MAY; be used as the
a HEAD response differs from that in a selected GET response, the cache
&MUST; consider that selected response to be stale.
If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
values of a HEAD response (when present) are the same as that in a selected
GET response (as per <xref target="caching.negotiated.responses"/>), the
cache &SHOULD; update the remaining headers in the stored response using the
<x:source basename="p1-messaging" href="p1-messaging.xml">