Source: https://trac.ietf.org/trac/httpbis/changeset/2398/draft-ietf-httpbis
Timestamp: 2020-07-15 18:22:24
Document Index: 161774634

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

Changeset 2398 for draft-ietf-httpbis – Hypertext Transfer Protocol Wiki
Changeset 2398 for draft-ietf-httpbis
14/09/13 23:59:24 (7 years ago)
<p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.
with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if
the key is pseudonymous.
<p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information,
In the interest of robustness, a server that is expecting to receive and
parse a request-line &SHOULD; ignore at least one empty line (CRLF)
received prior to the request-line.
Recipients &SHOULD; carefully limit the extent to which they read other
Recipients ought to carefully limit the extent to which they read other
fields, including (but not limited to) request methods, response status
phrases, header field-names, and body chunks, so as to avoid denial of
but is generally not sufficient to prevent real log traces from being
re-identified based on correlation with other access characteristics.
As such, access traces that are keyed to a specific client should not
be published even if the key is pseudonymous.
As such, access traces that are keyed to a specific client are unsafe to
publish even if the key is pseudonymous.
To minimize the risk of theft or accidental publication, log information
should be purged of personally identifiable information, including
ought to be purged of personally identifiable information, including
user identifiers, IP addresses, and user-provided query parameters,
as soon as that information is no longer necessary to support operational
<p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", then the origin server <em class="bcp14">SHOULD</em> do one of:
<p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:
<p id="rfc.section.5.3.2.p.6">The example</p>
</pre><p id="rfc.section.5.3.2.p.8"><em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
</pre><p id="rfc.section.5.3.2.p.8">is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
<x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT
has a Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
has a Content-Type of "image/jpeg", the origin server ought to do one of:
<t>reconfigure the target resource to reflect the new media type;</t>
is interpreted as "I prefer audio/basic, but send me any audio
server needs to incorporate additional information in the validator to
distinguish those representations.
itself with an origin server &mdash; usually, but not necessarily, after receiving a <x:ref>401
(Unauthorized)</x:ref> response. Its value consists of credentials containing
information of the user agent for the realm of the resource being
The "Authorization" header field allows a user agent to authenticate itself
with an origin server &mdash; usually, but not necessarily, after receiving
a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
credentials containing the authentication information of the user agent for
If a request is authenticated and a realm specified, the same credentials
are presumed to be valid for all other requests within this realm (assuming
that the authentication scheme itself does not require otherwise, such as
credentials that vary according to a challenge value or using synchronized
clocks).