Source: https://trac.ietf.org/trac/httpbis/changeset/2575/
Timestamp: 2020-04-08 03:04:55
Document Index: 140256766

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

Changeset 2575 – Hypertext Transfer Protocol Wiki
23/01/14 22:06:12 (6 years ago)
(editorial) move requirements specific to a given header field to where the field is defined; properly target requirements to roles; see #536
p7-auth.html (modified) (15 diffs)
p7-auth.xml (modified) (9 diffs)
<p id="rfc.section.2.1.p.5">A <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent, including a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.
<p id="rfc.section.2.1.p.6">A <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client, including a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing at least one challenge applicable to the proxy for the requested resource.
<p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that omits proxy credentials or contains invalid or partial proxy credentials, a proxy
<p id="rfc.section.2.1.p.15">A server that receives valid credentials which are not adequate to gain access ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
<p id="rfc.section.2.1.p.17">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.2</a>.
<p id="rfc.section.2.2.p.1">The "<dfn>realm</dfn>" authentication parameter is reserved for use by authentication schemes that wish to indicate a scope of protection.
resource. The origin server <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.1</a>) containing at least one challenge applicable to the target resource. If the request included authentication credentials,
then the 401 response indicates that authorization has been refused for those credentials. The user agent <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.2</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
resource. The server generating a 401 response <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.1</a>) containing at least one challenge applicable to the target resource.
<p id="rfc.section.3.1.p.2">If the request included authentication credentials, then the 401 response indicates that authorization has been refused for
those credentials. The user agent <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.2</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
<h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></h2>
<p id="rfc.section.4.1.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
applicable to 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.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
<p id="rfc.section.4.1.p.2">It <em class="bcp14">MUST</em> be included in <a href="#status.401" class="smpl">401 (Unauthorized)</a> response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
<p id="rfc.section.4.1.p.1">The "WWW-Authenticate" header field indicates the authentication scheme(s) and parameters applicable to the target resource.</p>
<div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
</pre><p id="rfc.section.4.1.p.4">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and
</pre><p id="rfc.section.4.1.p.3">A server generating a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response <em class="bcp14">MUST</em> send a WWW-Authenticate header field containing at least one challenge. A server <em class="bcp14">MAY</em> generate a WWW-Authenticate header field in other response messages to indicate that supplying credentials (or different credentials)
might affect the response.
<p id="rfc.section.4.1.p.4">A proxy forwarding a response <em class="bcp14">MUST NOT</em> modify any <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> fields in that response.
<p id="rfc.section.4.1.p.5">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and
<div class="note" id="rfc.section.4.1.p.6">
<div class="note" id="rfc.section.4.1.p.7">
<p id="rfc.section.4.2.p.4">See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
<p id="rfc.section.4.2.p.4">A proxy forwarding a request <em class="bcp14">MUST NOT</em> modify any <a href="#header.authorization" class="smpl">Authorization</a> fields in that request. See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches.
<h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
<p id="rfc.section.4.3.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
applicable to the proxy for this 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.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). A proxy <em class="bcp14">MUST</em> send at least one Proxy-Authenticate header field in each <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that it generates.
to ensure that the connection cannot be used by any party other than the authenticated user (see <a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
<td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section&nbsp;4.2</a>
<td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.2</a>
<p id="rfc.section.6.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP authentication.
More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
<p id="rfc.section.6.p.2">Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not
<p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</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> for the Acknowledgments related to this document revision.
<p id="rfc.section.C.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
<li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">2.1</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.a.1"><b>4.2</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
<li>Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.authorization.1">3.1</a>, <a href="#rfc.iref.a.1"><b>4.2</b></a>, <a href="#rfc.xref.header.authorization.2">5.3</a></li>
<li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.1</a>, <a href="#rfc.xref.Part1.5">4.3</a>, <a href="#rfc.xref.Part1.6">5.1.2</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a>, <a href="#rfc.xref.Part1.14">C</a><ul>
<li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.3</a>, <a href="#rfc.xref.Part1.5">5.1.2</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#Part1"><b>8.1</b></a>, <a href="#rfc.xref.Part1.8">B</a>, <a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">C</a><ul>
<li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">C</a></li>
<li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">5.1.2</a></li>
<li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.1</a>, <a href="#rfc.xref.Part1.5">4.3</a></li>
<li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">2.2</a>, <a href="#rfc.xref.Part1.4">4.3</a></li>
<li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">7</a></li>
excluding whitespace (<xref target="RFC4648"/>).
The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
(<xref target="RFC4648"/>).
A <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin
server to challenge the authorization of a user agent, including a
<x:ref>WWW-Authenticate</x:ref> header field containing at least one
The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
used by a proxy to challenge the authorization of a client and &MUST;
include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
one challenge applicable to the proxy for the requested resource.
A <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
used by a proxy to challenge the authorization of a client, including a
<x:ref>Proxy-Authenticate</x:ref> header field containing at least one
challenge applicable to the proxy for the requested resource.
<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/>
&mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
&mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
&mdash; usually, but not necessarily, after receiving a
<x:ref>401 (Unauthorized)</x:ref> &mdash; can do so by including an
<x:ref>Authorization</x:ref> header field with the request.
but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
&mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
but not necessarily, after receiving a
<x:ref>407 (Proxy Authentication Required)</x:ref> &mdash; can do so by
including a <x:ref>Proxy-Authorization</x:ref> header field with the
(e.g., when the authentication scheme requires more than one round trip),
an origin server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response
that contains a <x:ref>WWW-Authenticate</x:ref> header field with at least
one (possibly new) challenge applicable to the requested resource.
Likewise, upon receipt of a request that omits proxy credentials or
contains invalid or partial proxy credentials, a proxy that requires
authentication &SHOULD; generate a
<x:ref>407 (Proxy Authentication Required)</x:ref> response that contains
a <x:ref>Proxy-Authenticate</x:ref> header field with at least one
access, ought to respond with the <x:ref>403 (Forbidden)</x:ref> status code (&status.403;).
However, such additional mechanisms are not defined by this specification.
A proxy &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
<x:ref>Authorization</x:ref> header fields unmodified and follow the rules
found in <xref target="header.authorization"/>.
<iref item="Canonical Root URI"/>
The "<x:dfn>realm</x:dfn>" authentication parameter is reserved for use by
authentication schemes that wish to indicate a scope of protection.
credentials for the target resource.
The server generating a 401 response &MUST; send a
<x:ref>WWW-Authenticate</x:ref> header field
(<xref target="header.www-authenticate"/>)
The "WWW-Authenticate" header field consists of at least one
applicable to the effective request URI (&effective-request-uri;).
It &MUST; be included in <x:ref>401 (Unauthorized)</x:ref> response messages and &MAY; be
included in other response messages to indicate that supplying credentials
(or different credentials) might affect the response.
The "WWW-Authenticate" header field indicates the authentication scheme(s)
and parameters applicable to the target resource.
<x:ref>WWW-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
A server generating a <x:ref>401 (Unauthorized)</x:ref> response
&MUST; send a WWW-Authenticate header field containing at least one
challenge. A server &MAY; generate a WWW-Authenticate header field
in other response messages to indicate that supplying credentials
A proxy forwarding a response &MUST-NOT; modify any
<x:ref>WWW-Authenticate</x:ref> fields in that response.
User agents are advised to take special care in parsing the field value, as
A proxy forwarding a request &MUST-NOT; modify any
<x:ref>Authorization</x:ref> fields in that request.
See &caching-authenticated-responses; for details of and requirements
pertaining to handling of the Authorization field by HTTP caches.