Changeset 1736 for draft-ietf-httpbis
- Timestamp:
- 08/07/12 12:30:37 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r1735 r1736 452 452 } 453 453 @bottom-center { 454 content: "Expires January 7, 2013";454 content: "Expires January 9, 2013"; 455 455 } 456 456 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">496 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <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 "HTTP/1.1" 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> 521 521 <tr> 522 <td class="left">Expires: January 7, 2013</td>522 <td class="left">Expires: January 9, 2013</td> 523 523 <td class="right">M. Nottingham, Editor</td> 524 524 </tr> … … 537 537 <tr> 538 538 <td class="left"></td> 539 <td class="right">July 6, 2012</td>539 <td class="right">July 8, 2012</td> 540 540 </tr> 541 541 </tbody> … … 567 567 in progress”. 568 568 </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> 570 570 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 571 571 <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 3.2.2</a>) does not appear in the response, if the cache is shared, and 853 853 </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 2.7</a>), and854 <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 2.7</a>), and 855 855 </li> 856 856 <li>the response either: … … 1160 1160 </p> 1161 1161 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <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 Authorizationheader 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. 1163 1163 </p> 1164 1164 <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 3.2.2</a>) have such an effect: must-revalidate, public, s-maxage. -
draft-ietf-httpbis/latest/p6-cache.xml
r1735 r1736 465 465 target="cache-response-directive" />) does not appear in the response, if 466 466 the cache is shared, and</t> 467 <t>the "Authorization"header field (see &header-authorization;) does not467 <t>the <x:ref>Authorization</x:ref> header field (see &header-authorization;) does not 468 468 appear in the request, if the cache is shared, unless the response 469 469 explicitly allows it (see <xref target="caching.authenticated.responses" … … 1051 1051 <section anchor="caching.authenticated.responses" 1052 1052 title="Shared Caching of Authenticated Responses"> 1053 1054 1053 <t> 1055 1054 A shared cache &MUST-NOT; use a cached response to a request with an 1056 Authorizationheader field (&header-authorization;) to satisfy any subsequent1055 <x:ref>Authorization</x:ref> header field (&header-authorization;) to satisfy any subsequent 1057 1056 request unless a cache directive that allows such responses to be stored is 1058 1057 present in the response. … … 2375 2374 </front> 2376 2375 <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> 2378 2379 </reference> 2379 2380 -
draft-ietf-httpbis/latest/p7-auth.html
r1735 r1736 449 449 } 450 450 @bottom-center { 451 content: "Expires January 7, 2013";451 content: "Expires January 9, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 6">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-08"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <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 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 7, 2013</td>522 <td class="left">Expires: January 9, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 6, 2012</td>527 <td class="right">July 8, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </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> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 699 699 </p> 700 700 </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 Authorizationheader 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. 702 702 </p> 703 703 <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. 704 704 </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 realm706 of the resource being requested, based upon a challenge received from the server (possibly at some point in the past). When707 creating their values, the user agent ought to do so by selecting the challenge with what it considers to be the most secure708 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. 709 709 </p> 710 710 <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. 722 722 </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 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 4.1</a>. 724 724 </p> 725 725 <div id="rfc.iref.p.1"></div> … … 799 799 </li> 800 800 <li> 801 <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect802 on HTTP caches as the "private" Cache-Controlresponse 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. 803 803 </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"). 807 806 </p> 808 807 </li> … … 812 811 <div id="rfc.iref.s.1"></div> 813 812 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorizationheader field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been813 <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 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 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been 815 814 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 816 815 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> 870 869 <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 authentication872 using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed873 by the first outbound proxythat 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 cooperatively870 </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 874 873 authenticate a given request. 875 874 </p> … … 1013 1012 </p> 1014 1013 <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 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. 1017 1015 </p> 1018 1016 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> -
draft-ietf-httpbis/latest/p7-auth.xml
r1726 r1736 260 260 The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server 261 261 to challenge the authorization of a user agent. This response &MUST; 262 include a WWW-Authenticateheader field containing at least one262 include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one 263 263 challenge applicable to the requested resource. 264 264 </t> 265 265 <t> 266 The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to267 challenge the authorization of a client and &MUST; include a Proxy-Authenticate268 header field containing at least one challenge269 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. 270 270 </t> 271 271 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/> … … 275 275 <t> 276 276 &Note; User agents will need to take special care in parsing the 277 WWW-Authenticate and Proxy-Authenticate header field values because they278 can contain more than one challenge, or if more than one of each is279 provided, since the contents of a challenge can itself contain a280 c omma-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. 281 281 </t> 282 282 </x:note> … … 291 291 A user agent that wishes to authenticate itself with an origin server 292 292 — usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref> 293 — can do so by including an Authorizationheader field with the293 — can do so by including an <x:ref>Authorization</x:ref> header field with the 294 294 request. 295 295 </t> … … 297 297 A client that wishes to authenticate itself with a proxy — usually, 298 298 but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref> 299 — can do so by including a Proxy-Authorizationheader field with the299 — can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the 300 300 request. 301 301 </t> 302 302 <t> 303 Both the Authorization field value and the Proxy-Authorizationfield value303 Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value 304 304 contain the client's credentials for the realm of the resource being 305 305 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., 317 317 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. 321 322 </t> 322 323 <t> … … 324 325 credentials or contain invalid or partial credentials, a proxy &SHOULD; 325 326 return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses 326 &MUST; include a Proxy-Authenticate headerfield containing a (possibly327 &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly 327 328 new) challenge applicable to the proxy. 328 329 </t> … … 340 341 </t> 341 342 <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"/>. 344 346 </t> 345 347 </section> … … 467 469 <t> 468 470 Authentication schemes need to document whether they are usable in 469 origin-server authentication (i.e., using WWW-Authenticate), and/or470 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>). 471 473 </t> 472 474 </x:lt> 473 475 <x:lt> 474 476 <t> 475 The credentials carried in an Authorizationheader field are specific to477 The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to 476 478 the User Agent, and therefore have the same effect on HTTP caches as the 477 479 "private" Cache-Control response directive, within the scope of the … … 480 482 <t> 481 483 Therefore, new authentication schemes which choose not to carry 482 credentials in the Authorization header(e.g., using a newly defined483 header ) will need to explicitly disallow caching, by mandating the use of484 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 484 486 either Cache-Control request directives (e.g., "no-store") or response 485 487 directives (e.g., "private"). … … 501 503 <t> 502 504 The request requires user authentication. The response &MUST; include a 503 WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge504 applicable to the target resource. The client &MAY; repeat the505 re quest with a suitable Authorization header field (<xref target="header.authorization"/>). If506 the request already included Authorization credentials, then the 401507 response indicates that authorization has been refused for those508 credentials. If the 401 response contains the same challenge as the509 prior response, and the user agent has already attempted505 <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 510 512 authentication at least once, then the user &SHOULD; be presented the 511 513 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 521 523 client ought to first authenticate itself with the proxy. The proxy &MUST; 522 return a Proxy-Authenticateheader field (<xref target="header.proxy-authenticate"/>) containing a524 return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a 523 525 challenge applicable to the proxy for the target resource. The 524 client &MAY; repeat the request with a suitable Proxy-Authorization526 client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref> 525 527 header field (<xref target="header.proxy-authorization"/>). 526 528 </t> … … 601 603 </artwork></figure> 602 604 <t> 603 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to604 the current connection, and intermediaries &SHOULD-NOT; forward it to605 downstream clients. However, an intermediate proxy might need to obtain its606 own credentials by requesting them from the downstream client, which in607 some circumstances will appear as if the proxy is forwarding the605 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 608 610 Proxy-Authenticate header field. 609 611 </t> 610 612 <t> 611 Note that the parsing considerations for WWW-Authenticate apply to this612 header field as well; see <xref target="header.www-authenticate"/> for613 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. 614 616 </t> 615 617 </section> … … 630 632 </artwork></figure> 631 633 <t> 632 Unlike Authorization, the Proxy-Authorization header field applies only to633 the next outbound proxy that demanded authentication using the Proxy-Authenticate634 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> 634 636 field. When multiple proxies are used in a chain, the 635 637 Proxy-Authorization header field is consumed by the first outbound … … 828 830 Possible mitigation strategies include restricting direct access to 829 831 authentication credentials (i.e., not making the content of the 830 Authorizationrequest header field available), and separating protection832 <x:ref>Authorization</x:ref> request header field available), and separating protection 831 833 spaces by using a different host name for each party. 832 834 </t>
Note: See TracChangeset
for help on using the changeset viewer.