Changeset 1736 for draft-ietf-httpbis

Timestamp:

08/07/12 12:30:37 (9 years ago)

Author:

julian.reschke@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (7 diffs)
• p6-cache.xml (modified) (3 diffs)
• p7-auth.html (modified) (10 diffs)
• p7-auth.xml (modified) (14 diffs)

draft-ietf-httpbis/latest/p6-cache.html

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -494 +494 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -537 +537 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -567 +567 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -852 +852 @@
          <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
          </li>
-         <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
+         <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
          </li>
          <li>the response either: 
@@ -1160 +1160 @@
       </p>
       <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>
-      <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.
+      <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.
       </p>
       <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

@@ -465 +465 @@
       target="cache-response-directive" />) does not appear in the response, if
       the cache is shared, and</t>
-      <t>the "Authorization" header field (see &header-authorization;) does not
+      <t>the <x:ref>Authorization</x:ref> header field (see &header-authorization;) does not
       appear in the request, if the cache is shared, unless the response
       explicitly allows it (see <xref target="caching.authenticated.responses"
@@ -1051 +1051 @@
 <section anchor="caching.authenticated.responses" 
    title="Shared Caching of Authenticated Responses">
-
 <t>
    A shared cache &MUST-NOT; use a cached response to a request with an
-   Authorization header field (&header-authorization;) to satisfy any subsequent
+   <x:ref>Authorization</x:ref> header field (&header-authorization;) to satisfy any subsequent
    request unless a cache directive that allows such responses to be stored is
    present in the response.
@@ -2375 +2374 @@
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-&ID-VERSION;" />
-    <x:source basename="p7-auth" href="p7-auth.xml" />
+    <x:source basename="p7-auth" href="p7-auth.xml">
+      <x:defines>Authorization</x:defines>
+    </x:source>
   </reference>
 

draft-ietf-httpbis/latest/p7-auth.html

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -699 +699 @@
          </p> 
       </div>
-      <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.
+      <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.
       </p>
       <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.
       </p>
-      <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
-         of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When
-         creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure
-         auth-scheme that it understands, obtaining credentials from the user as appropriate.
+      <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,
+         based upon a challenge received from the server (possibly at some point in the past). When creating their values, the user
+         agent ought to do so by selecting the challenge with what it considers to be the most secure auth-scheme that it understands,
+         obtaining credentials from the user as appropriate.
       </p>
       <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> ) ]
@@ -721 +721 @@
          authentication information. However, such additional mechanisms are not defined by this specification.
       </p>
-      <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>.
+      <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>.
       </p>
       <div id="rfc.iref.p.1"></div>
@@ -799 +799 @@
          </li>
          <li>
-            <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect
-               on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in.
+            <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
+               response directive, within the scope of the request they appear in.
             </p>
-            <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly
-               defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives
-               (e.g., "no-store") or response directives (e.g., "private").
+            <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
+               either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
             </p>
          </li>
@@ -812 +811 @@
       <div id="rfc.iref.s.1"></div>
       <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>
-      <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
+      <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
          refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
          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
@@ -869 +868 @@
       </p>
       <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>
-</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
-         using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed
-         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
+</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
+         field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed 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
          authenticate a given request.
       </p>
@@ -1013 +1012 @@
       </p>
       <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
-         of the Authorization request header field available), and separating protection spaces by using a different host name for
-         each party.
+         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.
       </p>
       <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

@@ -260 +260 @@
    The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    to challenge the authorization of a user agent. This response &MUST;
-   include a WWW-Authenticate header field containing at least one
+   include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
    challenge applicable to the requested resource.
 </t>
 <t>   
-   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
-   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
-   header field containing at least one challenge
-   applicable to the proxy for the requested resource.
+   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
+   used by a proxy to challenge the authorization of a client and &MUST;
+   include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
+   one challenge applicable to the proxy for the requested resource.
 </t>
 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/>
@@ -275 +275 @@
   <t>
      &Note; User agents will need to take special care in parsing the
-     WWW-Authenticate and Proxy-Authenticate header field values because they
-     can contain more than one challenge, or if more than one of each is
-     provided, since the contents of a challenge can itself contain a
-     comma-separated list of authentication parameters.
+     <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>
+     header field values because they can contain more than one challenge, or
+     if more than one of each is provided, since the contents of a challenge
+     can itself contain a comma-separated list of authentication parameters.
   </t>
 </x:note>
@@ -291 +291 @@
    A user agent that wishes to authenticate itself with an origin server
    &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
-   &mdash; can do so by including an Authorization header field with the
+   &mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
    request.
 </t>
@@ -297 +297 @@
    A client that wishes to authenticate itself with a proxy &mdash; usually,
    but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
-   &mdash; can do so by including a Proxy-Authorization header field with the
+   &mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
    request.
 </t>
 <t>
-   Both the Authorization field value and the Proxy-Authorization field value
+   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    contain the client's credentials for the realm of the resource being
    requested, based upon a challenge received from the server (possibly at
@@ -316 +316 @@
    invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    when the authentication scheme requires more than one round trip), an origin
-   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST;
-   include a WWW-Authenticate header field containing at least one (possibly
-   new) challenge applicable to the requested resource.
+   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such
+   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
+   containing at least one (possibly new) challenge applicable to the
+   requested resource.
 </t>
 <t>
@@ -324 +325 @@
    credentials or contain invalid or partial credentials, a proxy &SHOULD;
    return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
-   &MUST; include a Proxy-Authenticate header field containing a (possibly
+   &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly
    new) challenge applicable to the proxy.
 </t>
@@ -340 +341 @@
 </t>
 <t>
-   Proxies &MUST; forward the WWW-Authenticate and Authorization headers
-   unmodified and follow the rules found in <xref target="header.authorization"/>.
+   Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
+   <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
+   found in <xref target="header.authorization"/>.
 </t>
 </section>
@@ -467 +469 @@
     <t>
       Authentication schemes need to document whether they are usable in
-      origin-server authentication (i.e., using WWW-Authenticate), and/or
-      proxy authentication (i.e., using Proxy-Authenticate).
+      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
+      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
     </t>
     </x:lt>
     <x:lt>
     <t>
-      The credentials carried in an Authorization header field are specific to
+      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
       the User Agent, and therefore have the same effect on HTTP caches as the
       "private" Cache-Control response directive, within the scope of the
@@ -480 +482 @@
     <t>
       Therefore, new authentication schemes which choose not to carry
-      credentials in the Authorization header (e.g., using a newly defined
-      header) will need to explicitly disallow caching, by mandating the use of
+      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
+      header field) will need to explicitly disallow caching, by mandating the use of
       either Cache-Control request directives (e.g., "no-store") or response
       directives (e.g., "private").
@@ -501 +503 @@
 <t>
    The request requires user authentication. The response &MUST; include a
-   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
-   applicable to the target resource. The client &MAY; repeat the
-   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
-   the request already included Authorization credentials, then the 401
-   response indicates that authorization has been refused for those
-   credentials. If the 401 response contains the same challenge as the
-   prior response, and the user agent has already attempted
+   <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
+   containing a challenge applicable to the target resource. The client &MAY;
+   repeat the request with a suitable <x:ref>Authorization</x:ref> header field
+   (<xref target="header.authorization"/>). If the request already included
+   Authorization credentials, then the 401 response indicates that authorization
+   has been refused for those credentials. If the 401 response contains the
+   same challenge as the prior response, and the user agent has already attempted
    authentication at least once, then the user &SHOULD; be presented the
    representation that was given in the response, since that representation might
@@ -520 +522 @@
    This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    client ought to first authenticate itself with the proxy. The proxy &MUST;
-   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
+   return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    challenge applicable to the proxy for the target resource. The
-   client &MAY; repeat the request with a suitable Proxy-Authorization
+   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
    header field (<xref target="header.proxy-authorization"/>).
 </t>
@@ -601 +603 @@
 </artwork></figure>
 <t>
-   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
-   the current connection, and intermediaries &SHOULD-NOT;  forward it to
-   downstream clients. However, an intermediate proxy might need to obtain its
-   own credentials by requesting them from the downstream client, which in
-   some circumstances will appear as if the proxy is forwarding the
+   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
+   applies only to the current connection, and intermediaries &SHOULD-NOT;
+   forward it to downstream clients. However, an intermediate proxy might need
+   to obtain its own credentials by requesting them from the downstream client,
+   which in some circumstances will appear as if the proxy is forwarding the
    Proxy-Authenticate header field.
 </t>
 <t>
-   Note that the parsing considerations for WWW-Authenticate apply to this
-   header field as well; see <xref target="header.www-authenticate"/> for
-   details.
+   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
+   apply to this header field as well; see <xref target="header.www-authenticate"/>
+   for details.
 </t>
 </section>
@@ -630 +632 @@
 </artwork></figure>
 <t>
-   Unlike Authorization, the Proxy-Authorization header field applies only to
-   the next outbound proxy that demanded authentication using the Proxy-Authenticate
+   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field applies only to
+   the next outbound proxy that demanded authentication using the <x:ref>Proxy-Authenticate</x:ref>
    field. When multiple proxies are used in a chain, the
    Proxy-Authorization header field is consumed by the first outbound
@@ -828 +830 @@
   Possible mitigation strategies include restricting direct access to
   authentication credentials (i.e., not making the content of the
-  Authorization request header field available), and separating protection
+  <x:ref>Authorization</x:ref> request header field available), and separating protection
   spaces by using a different host name for each party.
 </t>