Changeset 2575


Ignore:
Timestamp:
23/01/14 22:06:12 (6 years ago)
Author:
fielding@…
Message:

(editorial) move requirements specific to a given header field to where the field is defined; properly target requirements to roles; see #536

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.html

    r2574 r2575  
    665665               with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>).
    666666            </p>
    667             <p id="rfc.section.2.1.p.5">The <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. This response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one challenge applicable to the requested resource.
    668             </p>
    669             <p id="rfc.section.2.1.p.6">The <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 and <em class="bcp14">MUST</em> include 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.
     667            <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.
     668            </p>
     669            <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.
    670670            </p>
    671671            <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#challenge.and.response" class="smpl">challenge</a>   = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
     
    689689               or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.
    690690            </p>
    691             <p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that requires authentication by proxies that omit credentials or contain invalid or partial
    692                credentials, a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy.
    693             </p>
    694             <p id="rfc.section.2.1.p.15">A server receiving credentials that are valid, but 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>).
     691            <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
     692               that requires authentication <em class="bcp14">SHOULD</em> generate a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with at least one (possibly new) challenge applicable to the proxy.
     693            </p>
     694            <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>).
    695695            </p>
    696696            <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
    697697               can be used, such as authentication at the transport level or via message encapsulation, and with additional header fields
    698698               specifying authentication information. However, such additional mechanisms are not defined by this specification.
    699             </p>
    700             <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>.
    701699            </p>
    702700         </div>
     
    706704            <div id="rfc.iref.c.1"></div>
    707705            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#protection.space">Protection Space (Realm)</a></h2>
    708             <p id="rfc.section.2.2.p.1">The authentication parameter realm is reserved for use by authentication schemes that wish to indicate the scope of protection.</p>
     706            <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.
     707            </p>
    709708            <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    710709               on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
     
    728727            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#status.401">401 Unauthorized</a></h2>
    729728            <p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target
    730                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,
    731                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
     729               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.
     730            </p>
     731            <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
     732               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
    732733               at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.
    733734            </p>
     
    746747            <div id="rfc.iref.w.1"></div>
    747748            <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>
    748             <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
    749                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>).
    750             </p>
    751             <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
    752                response.
    753             </p>
     749            <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>
    754750            <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>
    755 </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
     751</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)
     752               might affect the response.
     753            </p>
     754            <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.
     755            </p>
     756            <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
    756757               each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur
    757758               multiple times.
     
    763764               "type" and "title", and another one for the "Basic" scheme with a realm value of "simple".
    764765            </p>
    765             <div class="note" id="rfc.section.4.1.p.6">
     766            <div class="note" id="rfc.section.4.1.p.7">
    766767               <p><b>Note:</b> The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be
    767768                  considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice,
     
    782783               according to a challenge value or using synchronized clocks).
    783784            </p>
    784             <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.
     785            <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.
    785786            </p>
    786787         </div>
     
    789790            <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>
    790791            <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
    791                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.
     792               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.4"><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.
    792793            </p>
    793794            <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
     
    845846                     <p>HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request <em class="bcp14">MUST</em> be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or
    846847                        bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken
    847                         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.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     848                        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>).
    848849                     </p>
    849850                  </li>
     
    944945                        <td class="left">http</td>
    945946                        <td class="left">standard</td>
    946                         <td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section&nbsp;4.2</a>
     947                        <td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.2</a>
    947948                        </td>
    948949                     </tr>
     
    977978         <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
    978979         <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.
    979             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>.
     980            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>.
    980981         </p>
    981982         <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
     
    10421043            Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements.
    10431044         </p>
    1044          <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.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for the Acknowledgments related to this document revision.
     1045         <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.
    10451046         </p>
    10461047      </div>
     
    11481149            character).
    11491150         </p>
    1150          <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
    1151          </p>
    1152          <div id="rfc.figure.u.9"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    1153   <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
    1154   <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    1155   <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     1151         <p id="rfc.section.B.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:
     1152         </p>
     1153         <div id="rfc.figure.u.9"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">BWS</a>           = &lt;BWS, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     1154  <a href="#imported.abnf" class="smpl">OWS</a>           = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>&gt;
     1155  <a href="#imported.abnf" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
     1156  <a href="#imported.abnf" class="smpl">token</a>         = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    11561157</pre></div>
    11571158      <div id="collected.abnf">
    11581159         <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a href="#collected.abnf">Collected ABNF</a></h1>
    1159          <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.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
     1160         <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>.
    11601161         </p>
    11611162         <div id="rfc.figure.u.10"></div><pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = credentials
     
    12321233            </li>
    12331234            <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
    1234                   <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>
     1235                  <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>
    12351236               </ul>
    12361237            </li>
     
    12641265            </li>
    12651266            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    1266                   <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>
    1267                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">C</a></li>
    1268                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">5.1.2</a></li>
     1267                  <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>
     1268                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">C</a></li>
     1269                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">5.1.2</a></li>
    12691270                        <li><em>Section 2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.1</a></li>
    1270                         <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">B</a>, <a href="#rfc.xref.Part1.11">B</a></li>
    1271                         <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">B</a>, <a href="#rfc.xref.Part1.13">B</a></li>
    1272                         <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>
     1271                        <li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">B</a>, <a href="#rfc.xref.Part1.10">B</a></li>
     1272                        <li><em>Section 3.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">B</a>, <a href="#rfc.xref.Part1.12">B</a></li>
     1273                        <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>
    12731274                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    1274                         <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">7</a></li>
     1275                        <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">7</a></li>
    12751276                     </ul>
    12761277                  </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2574 r2575  
    188188</artwork></figure>
    189189<t>
    190    The "token68" syntax allows the 66 unreserved URI characters (<xref target="RFC3986"/>),
    191    plus a few others, so that it can hold a base64, base64url (URL and filename
    192    safe alphabet), base32, or base16 (hex) encoding, with or without padding, but
    193    excluding whitespace (<xref target="RFC4648"/>).
    194 </t>
    195 <t>
    196    The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    197    to challenge the authorization of a user agent. This response &MUST;
    198    include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
     190   The "token68" syntax allows the 66 unreserved URI characters
     191   (<xref target="RFC3986"/>), plus a few others, so that it can hold a
     192   base64, base64url (URL and filename safe alphabet), base32, or base16 (hex)
     193   encoding, with or without padding, but excluding whitespace
     194   (<xref target="RFC4648"/>).
     195</t>
     196<t>
     197   A <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin
     198   server to challenge the authorization of a user agent, including a
     199   <x:ref>WWW-Authenticate</x:ref> header field containing at least one
    199200   challenge applicable to the requested resource.
    200201</t>
    201202<t>   
    202    The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
    203    used by a proxy to challenge the authorization of a client and &MUST;
    204    include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
    205    one challenge applicable to the proxy for the requested resource.
     203   A <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
     204   used by a proxy to challenge the authorization of a client, including a
     205   <x:ref>Proxy-Authenticate</x:ref> header field containing at least one
     206   challenge applicable to the proxy for the requested resource.
    206207</t>
    207208<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/>
     
    217218<t>
    218219   A user agent that wishes to authenticate itself with an origin server
    219    &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
    220    &mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
    221    request.
     220   &mdash; usually, but not necessarily, after receiving a
     221   <x:ref>401 (Unauthorized)</x:ref> &mdash; can do so by including an
     222   <x:ref>Authorization</x:ref> header field with the request.
    222223</t>
    223224<t>   
    224225   A client that wishes to authenticate itself with a proxy &mdash; usually,
    225    but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
    226    &mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
     226   but not necessarily, after receiving a
     227   <x:ref>407 (Proxy Authentication Required)</x:ref> &mdash; can do so by
     228   including a <x:ref>Proxy-Authorization</x:ref> header field with the
    227229   request.
    228230</t>
     
    246248   Upon receipt of a request for a protected resource that omits credentials,
    247249   contains invalid credentials (e.g., a bad password) or partial credentials
    248    (e.g., when the authentication scheme requires more than one round trip), an
    249    origin server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response that
    250    contains a <x:ref>WWW-Authenticate</x:ref> header field with at least one
    251    (possibly new) challenge applicable to the requested resource.
    252 </t>
    253 <t>
    254    Likewise, upon receipt of a request that requires authentication by proxies
    255    that omit credentials or contain invalid or partial credentials, a proxy
    256    &SHOULD; send a <x:ref>407 (Proxy Authentication Required)</x:ref> response
    257    that contains a <x:ref>Proxy-Authenticate</x:ref> header field with a
     250   (e.g., when the authentication scheme requires more than one round trip),
     251   an origin server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response
     252   that contains a <x:ref>WWW-Authenticate</x:ref> header field with at least
     253   one (possibly new) challenge applicable to the requested resource.
     254</t>
     255<t>
     256   Likewise, upon receipt of a request that omits proxy credentials or
     257   contains invalid or partial proxy credentials, a proxy that requires
     258   authentication &SHOULD; generate a
     259   <x:ref>407 (Proxy Authentication Required)</x:ref> response that contains
     260   a <x:ref>Proxy-Authenticate</x:ref> header field with at least one
    258261   (possibly new) challenge applicable to the proxy.
    259262</t>
    260263<t>
    261    A server receiving credentials that are valid, but not adequate to gain
    262    access, ought to respond with the <x:ref>403 (Forbidden)</x:ref> status code (&status.403;).
     264   A server that receives valid credentials which are not adequate to gain
     265   access ought to respond with the <x:ref>403 (Forbidden)</x:ref> status
     266   code (&status.403;).
    263267</t>
    264268<t>
     
    269273   However, such additional mechanisms are not defined by this specification.
    270274</t>
    271 <t>
    272    A proxy &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
    273    <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
    274    found in <xref target="header.authorization"/>.
    275 </t>
    276275</section>
    277276
     
    281280  <iref item="Canonical Root URI"/>
    282281<t>
    283    The authentication parameter realm is reserved for use by authentication
    284    schemes that wish to indicate the scope of protection.
     282   The "<x:dfn>realm</x:dfn>" authentication parameter is reserved for use by
     283   authentication schemes that wish to indicate a scope of protection.
    285284</t>
    286285<t>
     
    324323   The <x:dfn>401 (Unauthorized)</x:dfn> status code indicates that the
    325324   request has not been applied because it lacks valid authentication
    326    credentials for the target resource. The origin server &MUST; send a
    327    <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
     325   credentials for the target resource.
     326   The server generating a 401 response &MUST; send a
     327   <x:ref>WWW-Authenticate</x:ref> header field
     328   (<xref target="header.www-authenticate"/>)
    328329   containing at least one challenge applicable to the target resource.
     330</t>
     331<t>
    329332   If the request included authentication credentials, then the 401 response
    330333   indicates that authorization has been refused for those credentials.
     
    337340</t>
    338341</section>
     342
    339343<section title="407 Proxy Authentication Required" anchor="status.407">
    340344  <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
     
    363367  <x:anchor-alias value="WWW-Authenticate"/>
    364368<t>
    365    The "WWW-Authenticate" header field consists of at least one
    366    challenge that indicates the authentication scheme(s) and parameters
    367    applicable to the effective request URI (&effective-request-uri;).
    368 </t>
    369 <t>   
    370    It &MUST; be included in <x:ref>401 (Unauthorized)</x:ref> response messages and &MAY; be
    371    included in other response messages to indicate that supplying credentials
    372    (or different credentials) might affect the response.
     369   The "WWW-Authenticate" header field indicates the authentication scheme(s)
     370   and parameters applicable to the target resource.
    373371</t>
    374372<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/>
    375373  <x:ref>WWW-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
    376374</artwork></figure>
     375<t>
     376   A server generating a <x:ref>401 (Unauthorized)</x:ref> response
     377   &MUST; send a WWW-Authenticate header field containing at least one
     378   challenge.  A server &MAY; generate a WWW-Authenticate header field
     379   in other response messages to indicate that supplying credentials
     380   (or different credentials) might affect the response.
     381</t>
     382<t>
     383   A proxy forwarding a response &MUST-NOT; modify any
     384   <x:ref>WWW-Authenticate</x:ref> fields in that response.
     385</t>
    377386<t>
    378387   User agents are advised to take special care in parsing the field value, as
     
    426435</t>
    427436<t>
     437   A proxy forwarding a request &MUST-NOT; modify any
     438   <x:ref>Authorization</x:ref> fields in that request.
    428439   See &caching-authenticated-responses; for details of and requirements
    429440   pertaining to handling of the Authorization field by HTTP caches.
Note: See TracChangeset for help on using the changeset viewer.