Changeset 1394 for draft-ietf-httpbis/latest/p7-auth.html
- Timestamp:
- 09/08/11 11:19:37 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r1388 r1394 359 359 } 360 360 @bottom-center { 361 content: "Expires February 9, 2012";361 content: "Expires February 10, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-08-0 8">406 <meta name="dct.issued" scheme="ISO8601" content="2011-08-09"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: February 9, 2012</td>437 <td class="left">Expires: February 10, 2012</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">August 8, 2011</td>490 <td class="right">August 9, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on February 9, 2012.</p>518 <p>This Internet-Draft will expire on February 10, 2012.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 638 638 <p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request 639 639 and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication 640 scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication 641 via that scheme. 642 </p> 643 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.a.1"></span><span id="rfc.iref.a.2"></span><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> auth-scheme = <a href="#core.rules" class="smpl">token</a> 640 scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be 641 a comma-separated list of attribute-value pairs or a single sequence of characters capable of holding base64-encoded information. 642 </p> 643 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.a.1"></span><span id="rfc.iref.a.2"></span><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.b.1"></span><span id="rfc.iref.g.3"></span> auth-scheme = <a href="#core.rules" class="smpl">token</a> 644 644 645 auth-param = <a href="#core.rules" class="smpl">token</a> <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) 645 </pre><p id="rfc.section.2.1.p.3">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. 646 </p> 647 <p id="rfc.section.2.1.p.4">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource. 648 </p> 649 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.g.3"></span> <a href="#challenge.and.response" class="smpl">challenge</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">auth-param</a> 650 </pre><div class="note" id="rfc.section.2.1.p.6"> 646 647 b64token = 1*( <a href="#notation" class="smpl">ALPHA</a> / <a href="#notation" class="smpl">DIGIT</a> / 648 "-" / "." / "_" / "~" / "+" / "/" ) *"=" 649 </pre><p id="rfc.section.2.1.p.3">The "b64token" syntax allows the 66 unreserved URI characters (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>), plus a few others, so that it can hold a base64, base64url (URL and filename safe alphabet), base32, or base16 (hex) encoding, 650 with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>). 651 </p> 652 <p id="rfc.section.2.1.p.4">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. 653 </p> 654 <p id="rfc.section.2.1.p.5">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource. 655 </p> 656 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.g.4"></span> <a href="#challenge.and.response" class="smpl">challenge</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 657 </pre><div class="note" id="rfc.section.2.1.p.7"> 651 658 <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate and Proxy-Authenticate header field values because 652 659 they can contain more than one challenge, or if more than one of each is provided, since the contents of a challenge can itself … … 654 661 </p> 655 662 </div> 656 <div class="note" id="rfc.section.2.1.p. 7">663 <div class="note" id="rfc.section.2.1.p.8"> 657 664 <p> <b>Note:</b> Many browsers fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported 658 665 schemes (such as "basic") first. 659 666 </p> 660 667 </div> 661 <p id="rfc.section.2.1.p. 8">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401668 <p id="rfc.section.2.1.p.9">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 662 669 (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. 663 670 </p> 664 <p id="rfc.section.2.1.p. 9">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication671 <p id="rfc.section.2.1.p.10">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication 665 672 Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. 666 673 </p> 667 <p id="rfc.section.2.1.p.1 0">Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication674 <p id="rfc.section.2.1.p.11">Both the Authorization field value and the Proxy-Authorization field value consist of credentials containing the authentication 668 675 information of the client for the realm of the resource being requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based 669 676 upon that challenge. 670 677 </p> 671 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.4"></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="#core.rules" class="smpl">token</a> 672 / <a href="#core.rules" class="smpl">quoted-string</a> 673 / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) 674 </pre><p id="rfc.section.2.1.p.12">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. 675 </p> 676 <p id="rfc.section.2.1.p.13">If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested 678 <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> ) ] 679 </pre><p id="rfc.section.2.1.p.13">If the origin server does not wish to accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. 680 </p> 681 <p id="rfc.section.2.1.p.14">If a proxy does not accept the credentials sent with a request, it <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required). The response <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested 677 682 resource. 678 683 </p> 679 <p id="rfc.section.2.1.p.1 4">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional684 <p id="rfc.section.2.1.p.15">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional 680 685 mechanisms <em class="bcp14">MAY</em> be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying 681 686 authentication information. However, such additional mechanisms are not defined by this specification. 682 687 </p> 683 <p id="rfc.section.2.1.p.1 5">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>.688 <p id="rfc.section.2.1.p.16">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>. 684 689 </p> 685 690 <div id="rfc.iref.p.1"></div> … … 687 692 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="protection.space" href="#protection.space">Protection Space (Realm)</a></h2> 688 693 <p id="rfc.section.2.2.p.1">The authentication parameter realm is reserved for use by authentication schemes that wish to indicate the scope of protection:</p> 689 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.r.2"></span><span id="rfc.iref.r.3"></span><span id="rfc.iref.g. 5"></span> realm = "realm" "=" realm-value694 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.r.2"></span><span id="rfc.iref.r.3"></span><span id="rfc.iref.g.6"></span> realm = "realm" "=" realm-value 690 695 realm-value = quoted-string 691 696 </pre><p id="rfc.section.2.2.p.3">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources … … 726 731 <li> 727 732 <p>The authentication parameter "realm" is reserved for defining Protection Spaces as defined in <a href="#protection.space" title="Protection Space (Realm)">Section 2.2</a>. New schemes <em class="bcp14">MUST NOT</em> use it in a way incompatible with that definition. 733 </p> 734 </li> 735 <li> 736 <p>The "b64token" notation was introduced for compatibility with existing authentication schemes and can only be used once per 737 challenge/credentials. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions 738 will be impossible. 728 739 </p> 729 740 </li> … … 744 755 </ul> 745 756 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> 746 <div id="rfc.iref.1 3"></div>757 <div id="rfc.iref.15"></div> 747 758 <div id="rfc.iref.s.1"></div> 748 759 <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> … … 752 763 information. 753 764 </p> 754 <div id="rfc.iref.1 4"></div>765 <div id="rfc.iref.16"></div> 755 766 <div id="rfc.iref.s.2"></div> 756 767 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> … … 767 778 for the realm of the resource being requested. 768 779 </p> 769 <div id="rfc.figure.u.6"></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>780 <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> 770 781 </pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials <em class="bcp14">SHOULD</em> be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, 771 782 such as credentials that vary according to a challenge value or using synchronized clocks). … … 790 801 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 791 802 </p> 792 <div id="rfc.figure.u.7"></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>803 <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> 793 804 </pre><p id="rfc.section.4.2.p.3">Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and <em class="bcp14">SHOULD NOT</em> be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting 794 805 them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate … … 802 813 the resource being requested. 803 814 </p> 804 <div id="rfc.figure.u.8"></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>815 <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> 805 816 </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 806 817 using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed … … 817 828 response. 818 829 </p> 819 <div id="rfc.figure.u.9"></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>830 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> 820 831 </pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one 821 832 challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a … … 962 973 <h2 id="rfc.references.2"><a href="#rfc.section.8.2" id="rfc.section.8.2">8.2</a> Informative References 963 974 </h2> 964 <table> 975 <table> 965 976 <tr> 966 977 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> … … 976 987 <td class="reference"><b id="RFC3864">[RFC3864]</b></td> 977 988 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 989 </td> 990 </tr> 991 <tr> 992 <td class="reference"><b id="RFC3986">[RFC3986]</b></td> 993 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005. 994 </td> 995 </tr> 996 <tr> 997 <td class="reference"><b id="RFC4648">[RFC4648]</b></td> 998 <td class="top">Josefsson, S., “<a href="http://tools.ietf.org/html/rfc4648">The Base16, Base32, and Base64 Data Encodings</a>”, RFC 4648, October 2006. 978 999 </td> 979 1000 </tr> … … 1006 1027 (<a href="#access.authentication.framework" title="Access Authentication Framework">Section 2</a>) 1007 1028 </p> 1008 <p id="rfc.section.A.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section 4</a>) 1029 <p id="rfc.section.A.p.2">The "b64token" alternative to auth-param lists has been added for consistency with legacy authentication schemes such as "Basic". 1030 (<a href="#access.authentication.framework" title="Access Authentication Framework">Section 2</a>) 1031 </p> 1032 <p id="rfc.section.A.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section 4</a>) 1009 1033 </p> 1010 1034 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1025 1049 <a href="#challenge.and.response" class="smpl">auth-scheme</a> = token 1026 1050 1027 <a href="#challenge.and.response" class="smpl">challenge</a> = auth-scheme 1*SP [ ( "," / auth-param ) *( OWS "," [ OWS 1028 auth-param ] ) ] 1029 <a href="#challenge.and.response" class="smpl">credentials</a> = auth-scheme 1*SP ( token / quoted-string / [ ( "," / 1030 auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) 1051 <a href="#challenge.and.response" class="smpl">b64token</a> = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) 1052 *"=" 1053 1054 <a href="#challenge.and.response" class="smpl">challenge</a> = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) *( 1055 OWS "," [ OWS auth-param ] ) ] ) ] 1056 <a href="#challenge.and.response" class="smpl">credentials</a> = auth-scheme [ 1*SP ( b64token / [ ( "," / auth-param ) 1057 *( OWS "," [ OWS auth-param ] ) ] ) ] 1031 1058 1032 1059 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 1.2.2> … … 1136 1163 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/177">http://tools.ietf.org/wg/httpbis/trac/ticket/177</a>>: "Realm required on challenges" 1137 1164 </li> 1165 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/195">http://tools.ietf.org/wg/httpbis/trac/ticket/195</a>>: "auth-param syntax" 1166 </li> 1138 1167 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/257">http://tools.ietf.org/wg/httpbis/trac/ticket/257</a>>: "Considerations for new authentications schemes" 1139 1168 </li> … … 1144 1173 </ul> 1145 1174 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1146 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index. C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a>1175 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a> 1147 1176 </p> 1148 1177 <div class="print2col"> 1149 1178 <ul class="ind"> 1150 1179 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1151 <li>401 Unauthorized (status code) <a href="#rfc.iref.1 3"><b>3.1</b></a>, <a href="#rfc.xref.status.401.1">5.2</a></li>1152 <li>407 Proxy Authentication Required (status code) <a href="#rfc.iref.1 4"><b>3.2</b></a>, <a href="#rfc.xref.status.407.1">5.2</a></li>1180 <li>401 Unauthorized (status code) <a href="#rfc.iref.15"><b>3.1</b></a>, <a href="#rfc.xref.status.401.1">5.2</a></li> 1181 <li>407 Proxy Authentication Required (status code) <a href="#rfc.iref.16"><b>3.2</b></a>, <a href="#rfc.xref.status.407.1">5.2</a></li> 1153 1182 </ul> 1154 1183 </li> … … 1157 1186 <li><tt>auth-scheme</tt> <a href="#rfc.iref.a.1"><b>2.1</b></a></li> 1158 1187 <li>Authorization header field <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.3"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li> 1188 </ul> 1189 </li> 1190 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 1191 <li><tt>b64token</tt> <a href="#rfc.iref.b.1"><b>2.1</b></a></li> 1159 1192 </ul> 1160 1193 </li> … … 1169 1202 <li><tt>auth-param</tt> <a href="#rfc.iref.g.2"><b>2.1</b></a></li> 1170 1203 <li><tt>auth-scheme</tt> <a href="#rfc.iref.g.1"><b>2.1</b></a></li> 1171 <li><tt>Authorization</tt> <a href="#rfc.iref.g.6"><b>4.1</b></a></li> 1172 <li><tt>challenge</tt> <a href="#rfc.iref.g.3"><b>2.1</b></a></li> 1173 <li><tt>credentials</tt> <a href="#rfc.iref.g.4"><b>2.1</b></a></li> 1174 <li><tt>Proxy-Authenticate</tt> <a href="#rfc.iref.g.7"><b>4.2</b></a></li> 1175 <li><tt>Proxy-Authorization</tt> <a href="#rfc.iref.g.8"><b>4.3</b></a></li> 1176 <li><tt>realm</tt> <a href="#rfc.iref.g.5"><b>2.2</b></a></li> 1177 <li><tt>WWW-Authenticate</tt> <a href="#rfc.iref.g.9"><b>4.4</b></a></li> 1204 <li><tt>Authorization</tt> <a href="#rfc.iref.g.7"><b>4.1</b></a></li> 1205 <li><tt>b64token</tt> <a href="#rfc.iref.g.3"><b>2.1</b></a></li> 1206 <li><tt>challenge</tt> <a href="#rfc.iref.g.4"><b>2.1</b></a></li> 1207 <li><tt>credentials</tt> <a href="#rfc.iref.g.5"><b>2.1</b></a></li> 1208 <li><tt>Proxy-Authenticate</tt> <a href="#rfc.iref.g.8"><b>4.2</b></a></li> 1209 <li><tt>Proxy-Authorization</tt> <a href="#rfc.iref.g.9"><b>4.3</b></a></li> 1210 <li><tt>realm</tt> <a href="#rfc.iref.g.6"><b>2.2</b></a></li> 1211 <li><tt>WWW-Authenticate</tt> <a href="#rfc.iref.g.10"><b>4.4</b></a></li> 1178 1212 </ul> 1179 1213 </li> … … 1220 1254 </li> 1221 1255 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">5.3</a>, <a href="#RFC3864"><b>8.2</b></a></li> 1256 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#RFC3986"><b>8.2</b></a></li> 1257 <li><em>RFC4648</em> <a href="#rfc.xref.RFC4648.1">2.1</a>, <a href="#RFC4648"><b>8.2</b></a></li> 1222 1258 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.3</a>, <a href="#RFC5226"><b>8.2</b></a><ul> 1223 1259 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.3</a></li>
Note: See TracChangeset
for help on using the changeset viewer.