Changeset 1736


Ignore:
Timestamp:
Jul 8, 2012, 5:30:37 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions(P7)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r1735 r1736  
    452452  }
    453453  @bottom-center {
    454        content: "Expires January 7, 2013";
     454       content: "Expires January 9, 2013";
    455455  }
    456456  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     496      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 7, 2013</td>
     522               <td class="left">Expires: January 9, 2013</td>
    523523               <td class="right">M. Nottingham, Editor</td>
    524524            </tr>
     
    537537            <tr>
    538538               <td class="left"></td>
    539                <td class="right">July 6, 2012</td>
     539               <td class="right">July 8, 2012</td>
    540540            </tr>
    541541         </tbody>
     
    567567         in progress”.
    568568      </p>
    569       <p>This Internet-Draft will expire on January 7, 2013.</p>
     569      <p>This Internet-Draft will expire on January 9, 2013.</p>
    570570      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    571571      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    852852         <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) does not appear in the response, if the cache is shared, and
    853853         </li>
    854          <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section&nbsp;2.7</a>), and
     854         <li>the <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section&nbsp;2.7</a>), and
    855855         </li>
    856856         <li>the response either:
     
    11601160      </p>
    11611161      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>
    1162       <p id="rfc.section.2.7.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an Authorization header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
     1162      <p id="rfc.section.2.7.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
    11631163      </p>
    11641164      <p id="rfc.section.2.7.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1735 r1736  
    465465      target="cache-response-directive" />) does not appear in the response, if
    466466      the cache is shared, and</t>
    467       <t>the "Authorization" header field (see &header-authorization;) does not
     467      <t>the <x:ref>Authorization</x:ref> header field (see &header-authorization;) does not
    468468      appear in the request, if the cache is shared, unless the response
    469469      explicitly allows it (see <xref target="caching.authenticated.responses"
     
    10511051<section anchor="caching.authenticated.responses"
    10521052   title="Shared Caching of Authenticated Responses">
    1053 
    10541053<t>
    10551054   A shared cache &MUST-NOT; use a cached response to a request with an
    1056    Authorization header field (&header-authorization;) to satisfy any subsequent
     1055   <x:ref>Authorization</x:ref> header field (&header-authorization;) to satisfy any subsequent
    10571056   request unless a cache directive that allows such responses to be stored is
    10581057   present in the response.
     
    23752374    </front>
    23762375    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" />
    2377     <x:source basename="p7-auth" href="p7-auth.xml" />
     2376    <x:source basename="p7-auth" href="p7-auth.xml">
     2377      <x:defines>Authorization</x:defines>
     2378    </x:source>
    23782379  </reference>
    23792380
  • draft-ietf-httpbis/latest/p7-auth.html

    r1735 r1736  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 7, 2013";
     451       content: "Expires January 9, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 7, 2013</td>
     522               <td class="left">Expires: January 9, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 6, 2012</td>
     527               <td class="right">July 8, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on January 7, 2013.</p>
     555      <p>This Internet-Draft will expire on January 9, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    699699         </p>
    700700      </div>
    701       <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an Authorization header field with the request.
     701      <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an <a href="#header.authorization" class="smpl">Authorization</a> header field with the request.
    702702      </p>
    703703      <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a Proxy-Authorization header field with the request.
    704704      </p>
    705       <p id="rfc.section.2.1.p.12">Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm
    706          of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When
    707          creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure
    708          auth-scheme that it understands, obtaining credentials from the user as appropriate.
     705      <p id="rfc.section.2.1.p.12">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the Proxy-Authorization field value contain the client's credentials for the realm of the resource being requested,
     706         based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user
     707         agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands,
     708         obtaining credentials from the user as appropriate.
    709709      </p>
    710710      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
     
    721721         authentication information. However, such additional mechanisms are not defined by this specification.
    722722      </p>
    723       <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;4.1</a>.
     723      <p id="rfc.section.2.1.p.18">Proxies <em class="bcp14">MUST</em> forward the WWW-Authenticate 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>.
    724724      </p>
    725725      <div id="rfc.iref.p.1"></div>
     
    799799         </li>
    800800         <li>
    801             <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect
    802                on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
     801            <p>The credentials carried in an <a href="#header.authorization" class="smpl">Authorization</a> header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control
     802               response directive, within the scope of the request they appear in.
    803803            </p>
    804             <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly
    805                defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives
    806                (e.g., "no-store") or response directives (e.g., "private").
     804            <p>Therefore, new authentication schemes which choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
     805               either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
    807806            </p>
    808807         </li>
     
    812811      <div id="rfc.iref.s.1"></div>
    813812      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
    814       <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
     813      <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <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 request already included Authorization credentials, then the 401 response indicates that authorization has been
    815814         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    816815         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
     
    869868      </p>
    870869      <div id="rfc.figure.u.7"></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>
    871 </pre><p id="rfc.section.4.3.p.3">Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication
    872          using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed
    873          by the first outbound proxy 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
     870</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 outbound proxy that demanded authentication using the Proxy-Authenticate
     871         field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy
     872         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
    874873         authenticate a given request.
    875874      </p>
     
    10131012      </p>
    10141013      <p id="rfc.section.6.2.p.2">This is of particular concern when a server hosts resources for multiple parties under the same canonical root URI (<a href="#protection.spaces" title="Protection Spaces">Section&nbsp;6.2</a>). Possible mitigation strategies include restricting direct access to authentication credentials (i.e., not making the content
    1015          of the Authorization request header field available), and separating protection spaces by using a different host name for
    1016          each party.
     1014         of the <a href="#header.authorization" class="smpl">Authorization</a> request header field available), and separating protection spaces by using a different host name for each party.
    10171015      </p>
    10181016      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1726 r1736  
    260260   The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    261261   to challenge the authorization of a user agent. This response &MUST;
    262    include a WWW-Authenticate header field containing at least one
     262   include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
    263263   challenge applicable to the requested resource.
    264264</t>
    265265<t>   
    266    The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
    267    challenge the authorization of a client and &MUST; include a Proxy-Authenticate
    268    header field containing at least one challenge
    269    applicable to the proxy for the requested resource.
     266   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
     267   used by a proxy to challenge the authorization of a client and &MUST;
     268   include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
     269   one challenge applicable to the proxy for the requested resource.
    270270</t>
    271271<figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/>
     
    275275  <t>
    276276     &Note; User agents will need to take special care in parsing the
    277      WWW-Authenticate and Proxy-Authenticate header field values because they
    278      can contain more than one challenge, or if more than one of each is
    279      provided, since the contents of a challenge can itself contain a
    280      comma-separated list of authentication parameters.
     277     <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>
     278     header field values because they can contain more than one challenge, or
     279     if more than one of each is provided, since the contents of a challenge
     280     can itself contain a comma-separated list of authentication parameters.
    281281  </t>
    282282</x:note>
     
    291291   A user agent that wishes to authenticate itself with an origin server
    292292   &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
    293    &mdash; can do so by including an Authorization header field with the
     293   &mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
    294294   request.
    295295</t>
     
    297297   A client that wishes to authenticate itself with a proxy &mdash; usually,
    298298   but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
    299    &mdash; can do so by including a Proxy-Authorization header field with the
     299   &mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
    300300   request.
    301301</t>
    302302<t>
    303    Both the Authorization field value and the Proxy-Authorization field value
     303   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    304304   contain the client's credentials for the realm of the resource being
    305305   requested, based upon a challenge received from the server (possibly at
     
    316316   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    317317   when the authentication scheme requires more than one round trip), an origin
    318    server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST;
    319    include a WWW-Authenticate header field containing at least one (possibly
    320    new) challenge applicable to the requested resource.
     318   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such
     319   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
     320   containing at least one (possibly new) challenge applicable to the
     321   requested resource.
    321322</t>
    322323<t>
     
    324325   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    325326   return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    326    &MUST; include a Proxy-Authenticate header field containing a (possibly
     327   &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly
    327328   new) challenge applicable to the proxy.
    328329</t>
     
    340341</t>
    341342<t>
    342    Proxies &MUST; forward the WWW-Authenticate and Authorization headers
    343    unmodified and follow the rules found in <xref target="header.authorization"/>.
     343   Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
     344   <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
     345   found in <xref target="header.authorization"/>.
    344346</t>
    345347</section>
     
    467469    <t>
    468470      Authentication schemes need to document whether they are usable in
    469       origin-server authentication (i.e., using WWW-Authenticate), and/or
    470       proxy authentication (i.e., using Proxy-Authenticate).
     471      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
     472      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
    471473    </t>
    472474    </x:lt>
    473475    <x:lt>
    474476    <t>
    475       The credentials carried in an Authorization header field are specific to
     477      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    476478      the User Agent, and therefore have the same effect on HTTP caches as the
    477479      "private" Cache-Control response directive, within the scope of the
     
    480482    <t>
    481483      Therefore, new authentication schemes which choose not to carry
    482       credentials in the Authorization header (e.g., using a newly defined
    483       header) will need to explicitly disallow caching, by mandating the use of
     484      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
     485      header field) will need to explicitly disallow caching, by mandating the use of
    484486      either Cache-Control request directives (e.g., "no-store") or response
    485487      directives (e.g., "private").
     
    501503<t>
    502504   The request requires user authentication. The response &MUST; include a
    503    WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
    504    applicable to the target resource. The client &MAY; repeat the
    505    request with a suitable Authorization header field (<xref target="header.authorization"/>). If
    506    the request already included Authorization credentials, then the 401
    507    response indicates that authorization has been refused for those
    508    credentials. If the 401 response contains the same challenge as the
    509    prior response, and the user agent has already attempted
     505   <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
     506   containing a challenge applicable to the target resource. The client &MAY;
     507   repeat the request with a suitable <x:ref>Authorization</x:ref> header field
     508   (<xref target="header.authorization"/>). If the request already included
     509   Authorization credentials, then the 401 response indicates that authorization
     510   has been refused for those credentials. If the 401 response contains the
     511   same challenge as the prior response, and the user agent has already attempted
    510512   authentication at least once, then the user &SHOULD; be presented the
    511513   representation that was given in the response, since that representation might
     
    520522   This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    521523   client ought to first authenticate itself with the proxy. The proxy &MUST;
    522    return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
     524   return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    523525   challenge applicable to the proxy for the target resource. The
    524    client &MAY; repeat the request with a suitable Proxy-Authorization
     526   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
    525527   header field (<xref target="header.proxy-authorization"/>).
    526528</t>
     
    601603</artwork></figure>
    602604<t>
    603    Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
    604    the current connection, and intermediaries &SHOULD-NOT;  forward it to
    605    downstream clients. However, an intermediate proxy might need to obtain its
    606    own credentials by requesting them from the downstream client, which in
    607    some circumstances will appear as if the proxy is forwarding the
     605   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
     606   applies only to the current connection, and intermediaries &SHOULD-NOT;
     607   forward it to downstream clients. However, an intermediate proxy might need
     608   to obtain its own credentials by requesting them from the downstream client,
     609   which in some circumstances will appear as if the proxy is forwarding the
    608610   Proxy-Authenticate header field.
    609611</t>
    610612<t>
    611    Note that the parsing considerations for WWW-Authenticate apply to this
    612    header field as well; see <xref target="header.www-authenticate"/> for
    613    details.
     613   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
     614   apply to this header field as well; see <xref target="header.www-authenticate"/>
     615   for details.
    614616</t>
    615617</section>
     
    630632</artwork></figure>
    631633<t>
    632    Unlike Authorization, the Proxy-Authorization header field applies only to
    633    the next outbound proxy that demanded authentication using the Proxy-Authenticate
     634   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field applies only to
     635   the next outbound proxy that demanded authentication using the <x:ref>Proxy-Authenticate</x:ref>
    634636   field. When multiple proxies are used in a chain, the
    635637   Proxy-Authorization header field is consumed by the first outbound
     
    828830  Possible mitigation strategies include restricting direct access to
    829831  authentication credentials (i.e., not making the content of the
    830   Authorization request header field available), and separating protection
     832  <x:ref>Authorization</x:ref> request header field available), and separating protection
    831833  spaces by using a different host name for each party.
    832834</t>
Note: See TracChangeset for help on using the changeset viewer.