Changeset 2455
- Timestamp:
- 31/10/13 12:59:09 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r2452 r2455 445 445 } 446 446 @bottom-center { 447 content: "Expires May 3, 2014";447 content: "Expires May 4, 2014"; 448 448 } 449 449 @bottom-right { … … 485 485 <meta name="dct.creator" content="Reschke, J. F."> 486 486 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 487 <meta name="dct.issued" scheme="ISO8601" content="2013-10-3 0">487 <meta name="dct.issued" scheme="ISO8601" content="2013-10-31"> 488 488 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 489 489 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."> … … 513 513 <tr> 514 514 <td class="left">Intended status: Standards Track</td> 515 <td class="right">October 3 0, 2013</td>515 <td class="right">October 31, 2013</td> 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: May 3, 2014</td>518 <td class="left">Expires: May 4, 2014</td> 519 519 <td class="right"></td> 520 520 </tr> … … 543 543 in progress”. 544 544 </p> 545 <p>This Internet-Draft will expire on May 3, 2014.</p>545 <p>This Internet-Draft will expire on May 4, 2014.</p> 546 546 </div> 547 547 <div id="rfc.copyrightnotice"> … … 665 665 <div id="rfc.figure.u.2"></div><pre class="inline"><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="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 666 666 </pre><div class="note" id="rfc.section.2.1.p.8"> 667 <p><b>Note:</b> User agents will need to take special care in parsing the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field values because they can contain more than one challenge, or if more than one of each is provided, since the contents668 of a challenge can itself contain a comma-separated list of authentication parameters.669 </p>670 </div>671 <div class="note" id="rfc.section.2.1.p.9">672 667 <p><b>Note:</b> Many clients fail to parse challenges containing unknown schemes. A workaround for this problem is to list well-supported 673 668 schemes (such as "basic") first. 674 669 </p> 675 670 </div> 676 <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.677 </p> 678 <p id="rfc.section.2.1.p.1 1">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 <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request.679 </p> 680 <p id="rfc.section.2.1.p.1 2">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received671 <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 <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. 672 </p> 673 <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 <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field with the request. 674 </p> 675 <p id="rfc.section.2.1.p.11">Both the <a href="#header.authorization" class="smpl">Authorization</a> field value and the <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> field value contain the client's credentials for the realm of the resource being requested, based upon a challenge received 681 676 in a response (possibly at some point in the past). When creating their values, the user agent ought to do so by selecting 682 677 the challenge with what it considers to be the most secure auth-scheme that it understands, obtaining credentials from the … … 684 679 </p> 685 680 <div id="rfc.figure.u.3"></div><pre class="inline"><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="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ] 686 </pre><p id="rfc.section.2.1.p.1 4">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password)681 </pre><p id="rfc.section.2.1.p.13">Upon receipt of a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) 687 682 or partial credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource. 688 683 </p> 689 <p id="rfc.section.2.1.p.1 5">Likewise, upon receipt of a request that requires authentication by proxies that omit credentials or contain invalid or partial684 <p id="rfc.section.2.1.p.14">Likewise, upon receipt of a request that requires authentication by proxies that omit credentials or contain invalid or partial 690 685 credentials, a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy. 691 686 </p> 692 <p id="rfc.section.2.1.p.1 6">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).693 </p> 694 <p id="rfc.section.2.1.p.1 7">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms687 <p id="rfc.section.2.1.p.15">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 688 </p> 689 <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms 695 690 can be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying 696 691 authentication information. However, such additional mechanisms are not defined by this specification. 697 692 </p> 698 <p id="rfc.section.2.1.p.1 8">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>.693 <p id="rfc.section.2.1.p.17">A proxy <em class="bcp14">MUST</em> forward the <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> and <a href="#header.authorization" class="smpl">Authorization</a> header fields unmodified and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>. 699 694 </p> 700 695 </div> … … 795 790 </p> 796 791 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> 797 </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 one798 challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a799 comma-separated list of authentication parameters.792 </pre><p id="rfc.section.4.4.p.4">User agents are advised to take special care in parsing the field value, as it might contain more than one challenge, and 793 each challenge can contain a comma-separated list of authentication parameters. Furthermore, the header field itself can occur 794 multiple times. 800 795 </p> 801 796 <div id="rfc.figure.u.8"></div> … … 1161 1156 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/513">http://tools.ietf.org/wg/httpbis/trac/ticket/513</a>>: "APPSDIR review of draft-ietf-httpbis-p7-auth-24" 1162 1157 </li> 1158 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/516">http://tools.ietf.org/wg/httpbis/trac/ticket/516</a>>: "note about WWW-A parsing potentially misleading" 1159 </li> 1163 1160 </ul> 1164 1161 <p id="rfc.section.D.1.p.2">Partly resolved issues: </p> -
draft-ietf-httpbis/latest/p7-auth.xml
r2452 r2455 204 204 <x:note> 205 205 <t> 206 &Note; User agents will need to take special care in parsing the207 <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>208 header field values because they can contain more than one challenge, or209 if more than one of each is provided, since the contents of a challenge210 can itself contain a comma-separated list of authentication parameters.211 </t>212 </x:note>213 <x:note>214 <t>215 206 &Note; Many clients fail to parse challenges containing unknown 216 207 schemes. A workaround for this problem is to list well-supported schemes … … 457 448 </artwork></figure> 458 449 <t> 459 User agents are advised to take special care in parsing the WWW-Authenticate 460 field value as it might contain more than one challenge, 461 or if more than one WWW-Authenticate header field is provided, the 462 contents of a challenge itself can contain a comma-separated list of 463 authentication parameters. 450 User agents are advised to take special care in parsing the field value, as 451 it might contain more than one challenge, and each challenge can contain a 452 comma-separated list of authentication parameters. Furthermore, the header 453 field itself can occur multiple times. 464 454 </t> 465 455 <figure> … … 1105 1095 "APPSDIR review of draft-ietf-httpbis-p7-auth-24" 1106 1096 </t> 1097 <t> 1098 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/516"/>: 1099 "note about WWW-A parsing potentially misleading" 1100 </t> 1107 1101 </list> 1108 1102 </t>
Note: See TracChangeset
for help on using the changeset viewer.