Changeset 1386 for draft-ietf-httpbis/latest/p7-auth.html
- Timestamp:
- 08/08/11 12:16:58 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p7-auth.html
r1385 r1386 359 359 } 360 360 @bottom-center { 361 content: "Expires February 8, 2012";361 content: "Expires February 9, 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 7">406 <meta name="dct.issued" scheme="ISO8601" content="2011-08-08"> 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 8, 2012</td>437 <td class="left">Expires: February 9, 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 7, 2011</td>490 <td class="right">August 8, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on February 8, 2012.</p>518 <p>This Internet-Draft will expire on February 9, 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> … … 632 632 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 633 633 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 634 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 634 <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 635 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 635 636 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1> 636 637 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2> … … 640 641 via that scheme. 641 642 </p> 642 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.a.1"></span><span id="rfc.iref.a.2"></span> auth-scheme = token643 auth-param = token "=" ( token / quoted-string)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> auth-scheme = <a href="#core.rules" class="smpl">token</a> 644 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> ) 644 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. 645 646 </p> … … 688 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> realm = "realm" "=" realm-value 689 690 realm-value = quoted-string 690 </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. 6"><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 resources691 </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 691 692 on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization 692 693 database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific … … 720 721 <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep 721 722 their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over 722 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>).723 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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 723 724 </p> 724 725 </li> … … 787 788 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 788 789 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable 789 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. 8"><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.790 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. 790 791 </p> 791 792 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> … … 811 812 <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> 812 813 <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 813 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>).814 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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 814 815 </p> 815 816 <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 … … 931 932 Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements. 932 933 </p> 933 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.934 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision. 934 935 </p> 935 936 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1010 1011 <div id="rfc.figure.u.10"></div> <pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = credentials 1011 1012 1013 <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in [Part1], Section 1.2.2> 1014 1012 1015 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 1.2.2> 1013 1016 … … 1019 1022 ] ) 1020 1023 1021 <a href="#challenge.and.response" class="smpl">auth-param</a> = token "="( token / quoted-string )1024 <a href="#challenge.and.response" class="smpl">auth-param</a> = token BWS "=" BWS ( token / quoted-string ) 1022 1025 <a href="#challenge.and.response" class="smpl">auth-scheme</a> = token 1023 1026 … … 1133 1136 </li> 1134 1137 <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" 1138 </li> 1139 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/287">http://tools.ietf.org/wg/httpbis/trac/ticket/287</a>>: "LWS in auth-param ABNF" 1135 1140 </li> 1136 1141 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/309">http://tools.ietf.org/wg/httpbis/trac/ticket/309</a>>: "credentials ABNF missing SP (still using implied LWS?)" … … 1181 1186 </li> 1182 1187 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1183 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6"> 2.2</a>, <a href="#rfc.xref.Part1.7">2.3.1</a>, <a href="#rfc.xref.Part1.8">4.2</a>, <a href="#rfc.xref.Part1.9">4.4</a>, <a href="#rfc.xref.Part1.10">7</a>, <a href="#Part1"><b>8.1</b></a><ul>1188 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.8">2.3.1</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a>, <a href="#rfc.xref.Part1.11">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1184 1189 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1185 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a> </li>1186 <li><em>Section 2.2</em> <a href="#rfc.xref.Part1. 7">2.3.1</a></li>1187 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1. 6">2.2</a>, <a href="#rfc.xref.Part1.8">4.2</a>, <a href="#rfc.xref.Part1.9">4.4</a></li>1188 <li><em>Section 12</em> <a href="#rfc.xref.Part1.1 0">7</a></li>1190 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 1191 <li><em>Section 2.2</em> <a href="#rfc.xref.Part1.8">2.3.1</a></li> 1192 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a></li> 1193 <li><em>Section 12</em> <a href="#rfc.xref.Part1.11">7</a></li> 1189 1194 </ul> 1190 1195 </li>
Note: See TracChangeset
for help on using the changeset viewer.