Changeset 2574 for draft-ietf-httpbis


Ignore:
Timestamp:
23/01/14 21:07:59 (6 years ago)
Author:
fielding@…
Message:

(editorial) move section on WWW-Authenticate to first field discussed, since we don't need them in alphabetical order

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

Legend:

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

    r2573 r2574  
    583583         </li>
    584584         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.definitions">Header Field Definitions</a><ul>
    585                <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li>
    586                <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li>
    587                <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li>
    588                <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li>
     585               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></li>
     586               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.authorization">Authorization</a></li>
     587               <li><a href="#rfc.section.4.3">4.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></li>
     588               <li><a href="#rfc.section.4.4">4.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></li>
    589589            </ul>
    590590         </li>
     
    698698               specifying authentication information. However, such additional mechanisms are not defined by this specification.
    699699            </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.1</a>.
     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>.
    701701            </p>
    702702         </div>
     
    728728            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#status.401">401 Unauthorized</a></h2>
    729729            <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.4</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.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
     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
    732732               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.
    733733            </p>
     
    736736            <div id="rfc.iref.8"></div>
    737737            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></h2>
    738             <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
     738            <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.3</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.4</a>).
    739739            </p>
    740740         </div>
     
    742742      <div id="header.field.definitions">
    743743         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#header.field.definitions">Header Field Definitions</a></h1>
    744          <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to authentication.</p>
     744         <p id="rfc.section.4.p.1">This section defines the syntax and semantics of header fields related to the HTTP authentication framework.</p>
     745         <div id="header.www-authenticate">
     746            <div id="rfc.iref.w.1"></div>
     747            <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>
     754            <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
     756               each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur
     757               multiple times.
     758            </p>
     759            <div id="rfc.figure.u.5"></div>
     760            <p>For instance:</p><pre class="text">  WWW-Authenticate: Newauth realm="apps", type=1,
     761                    title="Login to \"apps\"", Basic realm="simple"
     762</pre><p>This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters
     763               "type" and "title", and another one for the "Basic" scheme with a realm value of "simple".
     764            </p>
     765            <div class="note" id="rfc.section.4.1.p.6">
     766               <p><b>Note:</b> The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be
     767                  considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice,
     768                  this ambiguity does not affect the semantics of the header field value and thus is harmless.
     769               </p>
     770            </div>
     771         </div>
    745772         <div id="header.authorization">
    746773            <div id="rfc.iref.a.1"></div>
    747             <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#header.authorization">Authorization</a></h2>
    748             <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily,
     774            <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#header.authorization">Authorization</a></h2>
     775            <p id="rfc.section.4.2.p.1">The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily,
    749776               after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Its value consists of credentials containing the authentication information of the user agent for the realm of the
    750777               resource being requested.
    751778            </p>
    752             <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    753 </pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests
     779            <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
     780</pre><p id="rfc.section.4.2.p.3">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests
    754781               within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary
    755782               according to a challenge value or using synchronized clocks).
    756783            </p>
    757             <p id="rfc.section.4.1.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.
     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.
    758785            </p>
    759786         </div>
    760787         <div id="header.proxy-authenticate">
    761788            <div id="rfc.iref.p.2"></div>
    762             <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    763             <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    764                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.
    765             </p>
    766             <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    767 </pre><p id="rfc.section.4.2.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only
     789            <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>
     790            <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            </p>
     793            <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>
     794</pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>, the Proxy-Authenticate header field applies only to the next outbound client on the response chain. This is because only
    768795               the client that chose a given proxy is likely to have the credentials necessary for authentication. However, when multiple
    769796               proxies are used within the same administrative domain, such as office and regional caching proxies within a large corporate
     
    772799               challenge set.
    773800            </p>
    774             <p id="rfc.section.4.2.p.4">Note that the parsing considerations for <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section&nbsp;4.4</a> for details.
     801            <p id="rfc.section.4.3.p.4">Note that the parsing considerations for <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> apply to this header field as well; see <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section&nbsp;4.1</a> for details.
    775802            </p>
    776803         </div>
    777804         <div id="header.proxy-authorization">
    778805            <div id="rfc.iref.p.3"></div>
    779             <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    780             <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication.
     806            <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#header.proxy-authorization">Proxy-Authorization</a></h2>
     807            <p id="rfc.section.4.4.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication.
    781808               Its value consists of credentials containing the authentication information of the client for the proxy and/or realm of the
    782809               resource being requested.
    783810            </p>
    784             <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
    785 </pre><p id="rfc.section.4.3.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy
     811            <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
     812</pre><p id="rfc.section.4.4.p.3">Unlike <a href="#header.authorization" class="smpl">Authorization</a>, the Proxy-Authorization header field applies only to the next inbound proxy that demanded authentication using the <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first inbound proxy
    786813               that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively
    787814               authenticate a given request.
    788815            </p>
    789          </div>
    790          <div id="header.www-authenticate">
    791             <div id="rfc.iref.w.1"></div>
    792             <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a href="#header.www-authenticate">WWW-Authenticate</a></h2>
    793             <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
    794                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.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    795             </p>
    796             <p id="rfc.section.4.4.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
    797                response.
    798             </p>
    799             <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.9"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
    800 </pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and
    801                each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur
    802                multiple times.
    803             </p>
    804             <div id="rfc.figure.u.8"></div>
    805             <p>For instance:</p><pre class="text">  WWW-Authenticate: Newauth realm="apps", type=1,
    806                     title="Login to \"apps\"", Basic realm="simple"
    807 </pre><p>This header field contains two challenges; one for the "Newauth" scheme with a realm value of "apps", and two additional parameters
    808                "type" and "title", and another one for the "Basic" scheme with a realm value of "simple".
    809             </p>
    810             <div class="note" id="rfc.section.4.4.p.6">
    811                <p><b>Note:</b> The challenge grammar production uses the list syntax as well. Therefore, a sequence of comma, whitespace, and comma can be
    812                   considered either as applying to the preceding challenge, or to be an empty entry in the list of challenges. In practice,
    813                   this ambiguity does not affect the semantics of the header field value and thus is harmless.
    814                </p>
    815             </div>
    816816         </div>
    817817      </div>
     
    944944                        <td class="left">http</td>
    945945                        <td class="left">standard</td>
    946                         <td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section&nbsp;4.1</a>
     946                        <td class="left"><a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section&nbsp;4.2</a>
    947947                        </td>
    948948                     </tr>
     
    951951                        <td class="left">http</td>
    952952                        <td class="left">standard</td>
    953                         <td class="left"><a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.2" title="Proxy-Authenticate">Section&nbsp;4.2</a>
     953                        <td class="left"><a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.2" title="Proxy-Authenticate">Section&nbsp;4.3</a>
    954954                        </td>
    955955                     </tr>
     
    958958                        <td class="left">http</td>
    959959                        <td class="left">standard</td>
    960                         <td class="left"><a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.2" title="Proxy-Authorization">Section&nbsp;4.3</a>
     960                        <td class="left"><a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.2" title="Proxy-Authorization">Section&nbsp;4.4</a>
    961961                        </td>
    962962                     </tr>
     
    965965                        <td class="left">http</td>
    966966                        <td class="left">standard</td>
    967                         <td class="left"><a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.3" title="WWW-Authenticate">Section&nbsp;4.4</a>
     967                        <td class="left"><a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.3" title="WWW-Authenticate">Section&nbsp;4.1</a>
    968968                        </td>
    969969                     </tr>
     
    12321232            </li>
    12331233            <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.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li>
     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>
    12351235               </ul>
    12361236            </li>
     
    12481248                        <li><tt>auth-param</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>2.1</b></a></li>
    12491249                        <li><tt>auth-scheme</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>2.1</b></a></li>
    1250                         <li><tt>Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>4.1</b></a></li>
     1250                        <li><tt>Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>4.2</b></a></li>
    12511251                        <li><tt>challenge</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>2.1</b></a></li>
    12521252                        <li><tt>credentials</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.5"><b>2.1</b></a></li>
    1253                         <li><tt>Proxy-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>4.2</b></a></li>
    1254                         <li><tt>Proxy-Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>4.3</b></a></li>
     1253                        <li><tt>Proxy-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>4.3</b></a></li>
     1254                        <li><tt>Proxy-Authorization</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>4.4</b></a></li>
    12551255                        <li><tt>token68</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>2.1</b></a></li>
    1256                         <li><tt>WWW-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.9"><b>4.4</b></a></li>
     1256                        <li><tt>WWW-Authenticate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.6"><b>4.1</b></a></li>
    12571257                     </ul>
    12581258                  </li>
     
    12641264            </li>
    12651265            <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.2</a>, <a href="#rfc.xref.Part1.5">4.4</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>
     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>
    12671267                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">C</a></li>
    12681268                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">5.1.2</a></li>
     
    12701270                        <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>
    12711271                        <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.2</a>, <a href="#rfc.xref.Part1.5">4.4</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>
    12731273                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.2</a></li>
    12741274                        <li><em>Section 10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">7</a></li>
     
    12791279                     </ul>
    12801280                  </li>
    1281                   <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a>, <a href="#rfc.xref.Part6.2">5.1.2</a>, <a href="#rfc.xref.Part6.3">5.1.2</a>, <a href="#Part6"><b>8.1</b></a><ul>
    1282                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.1</a></li>
     1281                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.2</a>, <a href="#rfc.xref.Part6.2">5.1.2</a>, <a href="#rfc.xref.Part6.3">5.1.2</a>, <a href="#Part6"><b>8.1</b></a><ul>
     1282                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">4.2</a></li>
    12831283                        <li><em>Section 5.2.1.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">5.1.2</a></li>
    12841284                        <li><em>Section 5.2.2.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">5.1.2</a></li>
     
    12861286                  </li>
    12871287                  <li>Protection Space&nbsp;&nbsp;<a href="#rfc.iref.p.1">2.2</a></li>
    1288                   <li>Proxy-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a href="#rfc.iref.p.2"><b>4.2</b></a>, <a href="#rfc.xref.header.proxy-authenticate.2">5.3</a></li>
    1289                   <li>Proxy-Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a href="#rfc.iref.p.3"><b>4.3</b></a>, <a href="#rfc.xref.header.proxy-authorization.2">5.3</a></li>
     1288                  <li>Proxy-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a href="#rfc.iref.p.2"><b>4.3</b></a>, <a href="#rfc.xref.header.proxy-authenticate.2">5.3</a></li>
     1289                  <li>Proxy-Authorization header field&nbsp;&nbsp;<a href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a href="#rfc.iref.p.3"><b>4.4</b></a>, <a href="#rfc.xref.header.proxy-authorization.2">5.3</a></li>
    12901290               </ul>
    12911291            </li>
     
    13121312            </li>
    13131313            <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
    1314                   <li>WWW-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a href="#rfc.xref.header.www-authenticate.2">4.2</a>, <a href="#rfc.iref.w.1"><b>4.4</b></a>, <a href="#rfc.xref.header.www-authenticate.3">5.3</a></li>
     1314                  <li>WWW-Authenticate header field&nbsp;&nbsp;<a href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a href="#rfc.iref.w.1"><b>4.1</b></a>, <a href="#rfc.xref.header.www-authenticate.2">4.3</a>, <a href="#rfc.xref.header.www-authenticate.3">5.3</a></li>
    13151315               </ul>
    13161316            </li>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2573 r2574  
    355355<section title="Header Field Definitions" anchor="header.field.definitions">
    356356<t>
    357    This section defines the syntax and semantics of HTTP/1.1 header fields
    358    related to authentication.
    359 </t>
    360 
    361 <section title="Authorization" anchor="header.authorization">
    362   <iref primary="true" item="Authorization header field" x:for-anchor=""/>
    363   <x:anchor-alias value="Authorization"/>
    364 <t>
    365    The "Authorization" header field allows a user agent to authenticate itself
    366    with an origin server &mdash; usually, but not necessarily, after receiving
    367    a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
    368    credentials containing the authentication information of the user agent for
    369    the realm of the resource being requested.
    370 </t>
    371 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
    372   <x:ref>Authorization</x:ref> = <x:ref>credentials</x:ref>
    373 </artwork></figure>
    374 <t>
    375    If a request is authenticated and a realm specified, the same credentials
    376    are presumed to be valid for all other requests within this realm (assuming
    377    that the authentication scheme itself does not require otherwise, such as
    378    credentials that vary according to a challenge value or using synchronized
    379    clocks).
    380 </t>
    381 <t>
    382    See &caching-authenticated-responses; for details of and requirements
    383    pertaining to handling of the Authorization field by HTTP caches.
    384 </t>
    385 </section>
    386 
    387 <section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
    388   <iref primary="true" item="Proxy-Authenticate header field" x:for-anchor=""/>
    389   <x:anchor-alias value="Proxy-Authenticate"/>
    390 <t>
    391    The "Proxy-Authenticate" header field consists of at least one
    392    challenge that indicates the authentication scheme(s) and parameters
    393    applicable to the proxy for this effective request URI
    394    (&effective-request-uri;).
    395    A proxy &MUST; send at least one Proxy-Authenticate header field in
    396    each <x:ref>407 (Proxy Authentication Required)</x:ref> response that it
    397    generates.
    398 </t>
    399 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
    400   <x:ref>Proxy-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
    401 </artwork></figure>
    402 <t>
    403    Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
    404    applies only to the next outbound client on the response chain.
    405    This is because only the client that chose a given proxy is likely to have
    406    the credentials necessary for authentication.  However, when multiple
    407    proxies are used within the same administrative domain, such as office and
    408    regional caching proxies within a large corporate network, it is common
    409    for credentials to be generated by the user agent and passed through the
    410    hierarchy until consumed.  Hence, in such a configuration, it will appear
    411    as if Proxy-Authenticate is being forwarded because each proxy will send
    412    the same challenge set.
    413 </t>
    414 <t>
    415    Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
    416    apply to this header field as well; see <xref target="header.www-authenticate"/>
    417    for details.
    418 </t>
    419 </section>
    420 
    421 <section title="Proxy-Authorization" anchor="header.proxy-authorization">
    422   <iref primary="true" item="Proxy-Authorization header field" x:for-anchor=""/>
    423   <x:anchor-alias value="Proxy-Authorization"/>
    424 <t>
    425    The "Proxy-Authorization" header field allows the client to
    426    identify itself (or its user) to a proxy that requires
    427    authentication. Its value consists of credentials containing the
    428    authentication information of the client for the proxy and/or realm of the
    429    resource being requested.
    430 </t>
    431 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
    432   <x:ref>Proxy-Authorization</x:ref> = <x:ref>credentials</x:ref>
    433 </artwork></figure>
    434 <t>
    435    Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field
    436    applies only to the next inbound proxy that demanded authentication using
    437    the <x:ref>Proxy-Authenticate</x:ref> field. When multiple proxies are used
    438    in a chain, the Proxy-Authorization header field is consumed by the first
    439    inbound proxy that was expecting to receive credentials. A proxy &MAY;
    440    relay the credentials from the client request to the next proxy if that is
    441    the mechanism by which the proxies cooperatively authenticate a given
    442    request.
    443 </t>
    444 </section>
     357   This section defines the syntax and semantics of header fields related to
     358   the HTTP authentication framework.
     359</t>
    445360
    446361<section title="WWW-Authenticate" anchor="header.www-authenticate">
     
    488403  </t>
    489404</x:note>
     405</section>
     406
     407<section title="Authorization" anchor="header.authorization">
     408  <iref primary="true" item="Authorization header field" x:for-anchor=""/>
     409  <x:anchor-alias value="Authorization"/>
     410<t>
     411   The "Authorization" header field allows a user agent to authenticate itself
     412   with an origin server &mdash; usually, but not necessarily, after receiving
     413   a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of
     414   credentials containing the authentication information of the user agent for
     415   the realm of the resource being requested.
     416</t>
     417<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/>
     418  <x:ref>Authorization</x:ref> = <x:ref>credentials</x:ref>
     419</artwork></figure>
     420<t>
     421   If a request is authenticated and a realm specified, the same credentials
     422   are presumed to be valid for all other requests within this realm (assuming
     423   that the authentication scheme itself does not require otherwise, such as
     424   credentials that vary according to a challenge value or using synchronized
     425   clocks).
     426</t>
     427<t>
     428   See &caching-authenticated-responses; for details of and requirements
     429   pertaining to handling of the Authorization field by HTTP caches.
     430</t>
     431</section>
     432
     433<section title="Proxy-Authenticate" anchor="header.proxy-authenticate">
     434  <iref primary="true" item="Proxy-Authenticate header field" x:for-anchor=""/>
     435  <x:anchor-alias value="Proxy-Authenticate"/>
     436<t>
     437   The "Proxy-Authenticate" header field consists of at least one
     438   challenge that indicates the authentication scheme(s) and parameters
     439   applicable to the proxy for this effective request URI
     440   (&effective-request-uri;).
     441   A proxy &MUST; send at least one Proxy-Authenticate header field in
     442   each <x:ref>407 (Proxy Authentication Required)</x:ref> response that it
     443   generates.
     444</t>
     445<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
     446  <x:ref>Proxy-Authenticate</x:ref> = 1#<x:ref>challenge</x:ref>
     447</artwork></figure>
     448<t>
     449   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
     450   applies only to the next outbound client on the response chain.
     451   This is because only the client that chose a given proxy is likely to have
     452   the credentials necessary for authentication.  However, when multiple
     453   proxies are used within the same administrative domain, such as office and
     454   regional caching proxies within a large corporate network, it is common
     455   for credentials to be generated by the user agent and passed through the
     456   hierarchy until consumed.  Hence, in such a configuration, it will appear
     457   as if Proxy-Authenticate is being forwarded because each proxy will send
     458   the same challenge set.
     459</t>
     460<t>
     461   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
     462   apply to this header field as well; see <xref target="header.www-authenticate"/>
     463   for details.
     464</t>
     465</section>
     466
     467<section title="Proxy-Authorization" anchor="header.proxy-authorization">
     468  <iref primary="true" item="Proxy-Authorization header field" x:for-anchor=""/>
     469  <x:anchor-alias value="Proxy-Authorization"/>
     470<t>
     471   The "Proxy-Authorization" header field allows the client to
     472   identify itself (or its user) to a proxy that requires
     473   authentication. Its value consists of credentials containing the
     474   authentication information of the client for the proxy and/or realm of the
     475   resource being requested.
     476</t>
     477<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authorization"/>
     478  <x:ref>Proxy-Authorization</x:ref> = <x:ref>credentials</x:ref>
     479</artwork></figure>
     480<t>
     481   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field
     482   applies only to the next inbound proxy that demanded authentication using
     483   the <x:ref>Proxy-Authenticate</x:ref> field. When multiple proxies are used
     484   in a chain, the Proxy-Authorization header field is consumed by the first
     485   inbound proxy that was expecting to receive credentials. A proxy &MAY;
     486   relay the credentials from the client request to the next proxy if that is
     487   the mechanism by which the proxies cooperatively authenticate a given
     488   request.
     489</t>
    490490</section>
    491491
Note: See TracChangeset for help on using the changeset viewer.