Changeset 1360 for draft-ietf-httpbis
- Timestamp:
- 27/07/11 13:21:29 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r1357 r1360 359 359 } 360 360 @bottom-center { 361 content: "Expires January 2 7, 2012";361 content: "Expires January 28, 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-07-2 6">406 <meta name="dct.issued" scheme="ISO8601" content="2011-07-27"> 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 HTTP Authentication."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: January 2 7, 2012</td>437 <td class="left">Expires: January 28, 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">July 2 6, 2011</td>490 <td class="right">July 27, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on January 2 7, 2012.</p>518 <p>This Internet-Draft will expire on January 28, 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> … … 716 716 <p id="rfc.section.2.3.1.p.2"> </p> 717 717 <ul> 718 <li>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep 719 their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over 720 which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</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>). 721 </li> 722 <li>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. 723 </li> 724 <li>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), 725 and/or proxy authentication (i.e., using Proxy-Authenticate). 718 <li> 719 <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep 720 their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over 721 which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</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>). 722 </p> 723 </li> 724 <li> 725 <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. 726 </p> 727 </li> 728 <li> 729 <p>Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), 730 and/or proxy authentication (i.e., using Proxy-Authenticate). 731 </p> 732 </li> 733 <li> 734 <p>The credentials carried in an Authorization header field are specific to the User Agent, and therefore have the same effect 735 on HTTP caches as the "private" Cache-Control response directive, within the scope of the request they appear in. 736 </p> 737 <p>Therefore, new authentication schemes which choose not to carry credentials in the Authorization header (e.g., using a newly 738 defined header) will need to explicitly disallow caching, by mandating the use of either Cache-Control request directives 739 (e.g., "no-store") or response directives (e.g., "private"). 740 </p> 726 741 </li> 727 742 </ul> … … 795 810 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 796 811 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters 797 applicable to the 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 in 401 (Unauthorized) response messages. 812 applicable to the 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>). 813 </p> 814 <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the 815 response. 798 816 </p> 799 817 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> 800 </pre><p id="rfc.section.4.4.p. 3">User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one818 </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 801 819 challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a 802 820 comma-separated list of authentication parameters. … … 1106 1124 <p id="rfc.section.C.17.p.1">Closed issues: </p> 1107 1125 <ul> 1126 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/78">http://tools.ietf.org/wg/httpbis/trac/ticket/78</a>>: "Relationship between 401, Authorization and WWW-Authenticate" 1127 </li> 1108 1128 <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" 1109 1129 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r1357 r1360 450 450 <t> 451 451 <list style="symbols"> 452 <x:lt> 452 453 <t> 453 454 Authentication schemes need to be compatible with the inherent … … 457 458 was received (see &msg-orient-and-buffering;). 458 459 </t> 460 </x:lt> 461 <x:lt> 459 462 <t> 460 463 The authentication parameter "realm" is reserved for defining Protection … … 462 465 &MUST-NOT; use it in a way incompatible with that definition. 463 466 </t> 467 </x:lt> 468 <x:lt> 464 469 <t> 465 470 Authentication schemes need to document whether they are usable in 466 471 origin-server authentication (i.e., using WWW-Authenticate), and/or 467 472 proxy authentication (i.e., using Proxy-Authenticate). 468 </t> 469 <!-- note about Authorization header --> 473 </t> 474 </x:lt> 475 <x:lt> 476 <t> 477 The credentials carried in an Authorization header field are specific to 478 the User Agent, and therefore have the same effect on HTTP caches as the 479 "private" Cache-Control response directive, within the scope of the 480 request they appear in. 481 </t> 482 <t> 483 Therefore, new authentication schemes which choose not to carry 484 credentials in the Authorization header (e.g., using a newly defined 485 header) will need to explicitly disallow caching, by mandating the use of 486 either Cache-Control request directives (e.g., "no-store") or response 487 directives (e.g., "private"). 488 </t> 489 </x:lt> 470 490 </list> 471 491 </t> … … 623 643 The "WWW-Authenticate" header field consists of at least one 624 644 challenge that indicates the authentication scheme(s) and parameters 625 applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401 626 (Unauthorized) response messages. 645 applicable to the effective request URI (&effective-request-uri;). 646 </t> 647 <t> 648 It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be 649 included in other response messages to indicate that supplying credentials 650 (or different credentials) might affect the response. 627 651 </t> 628 652 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/> … … 1256 1280 <list style="symbols"> 1257 1281 <t> 1282 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/78"/>: 1283 "Relationship between 401, Authorization and WWW-Authenticate" 1284 </t> 1285 <t> 1258 1286 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/177"/>: 1259 1287 "Realm required on challenges"
Note: See TracChangeset
for help on using the changeset viewer.