![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 998
- Timestamp:
- Sep 13, 2010, 7:47:24 AM (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
-
p2-semantics.html (modified) (17 diffs)
-
p2-semantics.xml (modified) (3 diffs)
-
p7-auth.html (modified) (31 diffs)
-
p7-auth.xml (modified) (16 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r994 r998 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-09- 07">405 <meta name="dct.issued" scheme="ISO8601" content="2010-09-13"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <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 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: March 1 1, 2011</td>436 <td class="left">Expires: March 17, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">September 7, 2010</td>489 <td class="right">September 13, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire on March 1 1, 2011.</p>516 <p>This Internet-Draft will expire on March 17, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 746 746 </pre><div id="rfc.figure.u.6"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Age</a> = <Age, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 3.1</a>> 747 747 <a href="#abnf.dependencies" class="smpl">Vary</a> = <Vary, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a>> 748 </pre><div id="rfc.figure.u.7"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Authorization</a> = <Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>>748 </pre><div id="rfc.figure.u.7"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Authorization</a> = <Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a>> 749 749 <a href="#abnf.dependencies" class="smpl">Proxy-Authenticate</a> = 750 <Proxy-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 3.2</a>>750 <Proxy-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a>> 751 751 <a href="#abnf.dependencies" class="smpl">Proxy-Authorization</a> = 752 <Proxy-Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 3.3</a>>752 <Proxy-Authorization, defined in <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a>> 753 753 <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> = 754 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>>754 <WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a>> 755 755 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 756 756 <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. … … 795 795 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> 796 796 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a> ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> 797 / <a href="#abnf.dependencies" class="smpl">Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>797 / <a href="#abnf.dependencies" class="smpl">Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> 798 798 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 799 799 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> … … 805 805 / <a href="#abnf.dependencies" class="smpl">If-Unmodified-Since</a> ; <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 6.5</a> 806 806 / <a href="#header.max-forwards" class="smpl">Max-Forwards</a> ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 9.5</a> 807 / <a href="#abnf.dependencies" class="smpl">Proxy-Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 3.3</a>807 / <a href="#abnf.dependencies" class="smpl">Proxy-Authorization</a> ; <a href="#Part7" id="rfc.xref.Part7.6"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 4.3</a> 808 808 / <a href="#abnf.dependencies" class="smpl">Range</a> ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 809 809 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> … … 815 815 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1> 816 816 <p id="rfc.section.4.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The status 817 codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 8</a>, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 2</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>.817 codes listed below are defined in <a href="#status.codes" title="Status Code Definitions">Section 8</a>, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>. 818 818 </p> 819 819 <p id="rfc.section.4.p.2">The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use … … 841 841 / "307" ; <a href="#status.307" id="rfc.xref.status.307.1" title="307 Temporary Redirect">Section 8.3.8</a>: Temporary Redirect 842 842 / "400" ; <a href="#status.400" id="rfc.xref.status.400.1" title="400 Bad Request">Section 8.4.1</a>: Bad Request 843 / "401" ; <a href="#Part7" id="rfc.xref.Part7.8"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#status.401" title="401 Unauthorized">Section 2.1</a>: Unauthorized843 / "401" ; <a href="#Part7" id="rfc.xref.Part7.8"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a>: Unauthorized 844 844 / "402" ; <a href="#status.402" id="rfc.xref.status.402.1" title="402 Payment Required">Section 8.4.3</a>: Payment Required 845 845 / "403" ; <a href="#status.403" id="rfc.xref.status.403.1" title="403 Forbidden">Section 8.4.4</a>: Forbidden … … 847 847 / "405" ; <a href="#status.405" id="rfc.xref.status.405.1" title="405 Method Not Allowed">Section 8.4.6</a>: Method Not Allowed 848 848 / "406" ; <a href="#status.406" id="rfc.xref.status.406.1" title="406 Not Acceptable">Section 8.4.7</a>: Not Acceptable 849 / "407" ; <a href="#Part7" id="rfc.xref.Part7.9"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 2.2</a>: Proxy Authentication Required849 / "407" ; <a href="#Part7" id="rfc.xref.Part7.9"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a>: Proxy Authentication Required 850 850 / "408" ; <a href="#status.408" id="rfc.xref.status.408.1" title="408 Request Timeout">Section 8.4.9</a>: Request Time-out 851 851 / "409" ; <a href="#status.409" id="rfc.xref.status.409.1" title="409 Conflict">Section 8.4.10</a>: Conflict … … 889 889 / <a href="#abnf.dependencies" class="smpl">ETag</a> ; <a href="#Part4" id="rfc.xref.Part4.13"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> 890 890 / <a href="#header.location" class="smpl">Location</a> ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 9.4</a> 891 / <a href="#abnf.dependencies" class="smpl">Proxy-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.10"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 3.2</a>891 / <a href="#abnf.dependencies" class="smpl">Proxy-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.10"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> 892 892 / <a href="#header.retry-after" class="smpl">Retry-After</a> ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 9.7</a> 893 893 / <a href="#header.server" class="smpl">Server</a> ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 9.8</a> 894 894 / <a href="#abnf.dependencies" class="smpl">Vary</a> ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> 895 / <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.11"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>895 / <a href="#abnf.dependencies" class="smpl">WWW-Authenticate</a> ; <a href="#Part7" id="rfc.xref.Part7.11"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> 896 896 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new 897 897 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header … … 1338 1338 <div id="rfc.iref.s.20"></div> 1339 1339 <h3 id="rfc.section.8.4.2"><a href="#rfc.section.8.4.2">8.4.2</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h3> 1340 <p id="rfc.section.8.4.2.p.1">The request requires user authentication (see <a href="p7-auth.html#status.401" title="401 Unauthorized">Section 2.1</a> of <a href="#Part7" id="rfc.xref.Part7.12"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>).1340 <p id="rfc.section.8.4.2.p.1">The request requires user authentication (see <a href="p7-auth.html#status.401" title="401 Unauthorized">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.12"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). 1341 1341 </p> 1342 1342 <div id="rfc.iref.44"></div> … … 1385 1385 <div id="rfc.iref.s.26"></div> 1386 1386 <h3 id="rfc.section.8.4.8"><a href="#rfc.section.8.4.8">8.4.8</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h3> 1387 <p id="rfc.section.8.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy (see <a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 2.2</a> of <a href="#Part7" id="rfc.xref.Part7.13"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>).1387 <p id="rfc.section.8.4.8.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy (see <a href="p7-auth.html#status.407" title="407 Proxy Authentication Required">Section 3.2</a> of <a href="#Part7" id="rfc.xref.Part7.13"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>). 1388 1388 </p> 1389 1389 <div id="rfc.iref.50"></div> … … 2275 2275 <a href="#header.allow" class="smpl">Allow</a> = "Allow:" OWS Allow-v 2276 2276 <a href="#header.allow" class="smpl">Allow-v</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 2277 <a href="#abnf.dependencies" class="smpl">Authorization</a> = <Authorization, defined in [Part7], Section 3.1>2277 <a href="#abnf.dependencies" class="smpl">Authorization</a> = <Authorization, defined in [Part7], Section 4.1> 2278 2278 2279 2279 <a href="#abnf.dependencies" class="smpl">ETag</a> = <ETag, defined in [Part4], Section 6.1> … … 2313 2313 2314 2314 Proxy-Authenticate = 2315 <Proxy-Authenticate, defined in [Part7], Section 3.2>2315 <Proxy-Authenticate, defined in [Part7], Section 4.2> 2316 2316 Proxy-Authorization = 2317 <Proxy-Authorization, defined in [Part7], Section 3.3>2317 <Proxy-Authorization, defined in [Part7], Section 4.3> 2318 2318 2319 2319 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in [Part1], Section 1.2.2> … … 2343 2343 2344 2344 WWW-Authenticate = 2345 <WWW-Authenticate, defined in [Part7], Section 3.4>2345 <WWW-Authenticate, defined in [Part7], Section 4.4> 2346 2346 2347 2347 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in [Part1], Section 2.6> … … 2789 2789 </li> 2790 2790 <li class="indline1"><em>Part7</em> <a class="iref" href="#rfc.xref.Part7.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.5">3</a>, <a class="iref" href="#rfc.xref.Part7.6">3</a>, <a class="iref" href="#rfc.xref.Part7.7">4</a>, <a class="iref" href="#rfc.xref.Part7.8">4</a>, <a class="iref" href="#rfc.xref.Part7.9">4</a>, <a class="iref" href="#rfc.xref.Part7.10">5</a>, <a class="iref" href="#rfc.xref.Part7.11">5</a>, <a class="iref" href="#rfc.xref.Part7.12">8.4.2</a>, <a class="iref" href="#rfc.xref.Part7.13">8.4.8</a>, <a class="iref" href="#Part7"><b>13.1</b></a><ul class="ind"> 2791 <li class="indline1"><em>Section 2</em> <a class="iref" href="#rfc.xref.Part7.7">4</a></li>2792 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part7.8">4</a>, <a class="iref" href="#rfc.xref.Part7.12">8.4.2</a></li>2793 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part7.9">4</a>, <a class="iref" href="#rfc.xref.Part7.13">8.4.8</a></li>2794 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.5">3</a></li>2795 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part7.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.10">5</a></li>2796 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part7.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.6">3</a></li>2797 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part7.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.11">5</a></li>2791 <li class="indline1"><em>Section 3</em> <a class="iref" href="#rfc.xref.Part7.7">4</a></li> 2792 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part7.8">4</a>, <a class="iref" href="#rfc.xref.Part7.12">8.4.2</a></li> 2793 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part7.9">4</a>, <a class="iref" href="#rfc.xref.Part7.13">8.4.8</a></li> 2794 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part7.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.5">3</a></li> 2795 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part7.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.10">5</a></li> 2796 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part7.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.6">3</a></li> 2797 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part7.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part7.11">5</a></li> 2798 2798 </ul> 2799 2799 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r994 r998 3319 3319 <x:ref>Allow</x:ref> = "Allow:" OWS Allow-v 3320 3320 <x:ref>Allow-v</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] 3321 <x:ref>Authorization</x:ref> = <Authorization, defined in [Part7], Section 3.1>3321 <x:ref>Authorization</x:ref> = <Authorization, defined in [Part7], Section 4.1> 3322 3322 3323 3323 <x:ref>ETag</x:ref> = <ETag, defined in [Part4], Section 6.1> … … 3357 3357 3358 3358 Proxy-Authenticate = 3359 <Proxy-Authenticate, defined in [Part7], Section 3.2>3359 <Proxy-Authenticate, defined in [Part7], Section 4.2> 3360 3360 Proxy-Authorization = 3361 <Proxy-Authorization, defined in [Part7], Section 3.3>3361 <Proxy-Authorization, defined in [Part7], Section 4.3> 3362 3362 3363 3363 <x:ref>RWS</x:ref> = <RWS, defined in [Part1], Section 1.2.2> … … 3387 3387 3388 3388 WWW-Authenticate = 3389 <WWW-Authenticate, defined in [Part7], Section 3.4>3389 <WWW-Authenticate, defined in [Part7], Section 4.4> 3390 3390 3391 3391 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [Part1], Section 2.6> -
draft-ietf-httpbis/latest/p7-auth.html
r994 r998 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 373 376 <link rel="Index" href="#rfc.index"> 374 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 375 <link rel="Chapter" title="2 Status Code Definitions" href="#rfc.section.2"> 376 <link rel="Chapter" title="3 Header Field Definitions" href="#rfc.section.3"> 377 <link rel="Chapter" title="4 IANA Considerations" href="#rfc.section.4"> 378 <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5"> 379 <link rel="Chapter" title="6 Acknowledgments" href="#rfc.section.6"> 380 <link rel="Chapter" href="#rfc.section.7" title="7 References"> 378 <link rel="Chapter" title="2 Access Authentication Framework" href="#rfc.section.2"> 379 <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"> 380 <link rel="Chapter" title="4 Header Field Definitions" href="#rfc.section.4"> 381 <link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"> 382 <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"> 383 <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"> 384 <link rel="Chapter" href="#rfc.section.8" title="8 References"> 381 385 <link rel="Appendix" title="A Collected ABNF" href="#rfc.section.A"> 382 386 <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B"> … … 393 397 <meta name="dct.creator" content="Reschke, J. F."> 394 398 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 395 <meta name="dct.issued" scheme="ISO8601" content="2010-09- 07">399 <meta name="dct.issued" scheme="ISO8601" content="2010-09-13"> 396 400 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 397 401 <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."> … … 424 428 </tr> 425 429 <tr> 426 <td class="left">Expires: March 1 1, 2011</td>430 <td class="left">Expires: March 17, 2011</td> 427 431 <td class="right">HP</td> 428 432 </tr> … … 477 481 <tr> 478 482 <td class="left"></td> 479 <td class="right">September 7, 2010</td>483 <td class="right">September 13, 2010</td> 480 484 </tr> 481 485 </tbody> … … 503 507 in progress”. 504 508 </p> 505 <p>This Internet-Draft will expire on March 1 1, 2011.</p>509 <p>This Internet-Draft will expire on March 17, 2011.</p> 506 510 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 507 511 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 525 529 <li class="tocline1">1.2 <a href="#notation">Syntax Notation</a><ul class="toc"> 526 530 <li class="tocline1">1.2.1 <a href="#core.rules">Core Rules</a></li> 527 <li class="tocline1">1.2.2 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>528 531 </ul> 529 532 </li> 530 533 </ul> 531 534 </li> 532 <li class="tocline0">2. <a href="#status.code.definitions">Status Code Definitions</a><ul class="toc"> 533 <li class="tocline1">2.1 <a href="#status.401">401 Unauthorized</a></li> 534 <li class="tocline1">2.2 <a href="#status.407">407 Proxy Authentication Required</a></li> 535 <li class="tocline0">2. <a href="#access.authentication.framework">Access Authentication Framework</a></li> 536 <li class="tocline0">3. <a href="#status.code.definitions">Status Code Definitions</a><ul class="toc"> 537 <li class="tocline1">3.1 <a href="#status.401">401 Unauthorized</a></li> 538 <li class="tocline1">3.2 <a href="#status.407">407 Proxy Authentication Required</a></li> 535 539 </ul> 536 540 </li> 537 <li class="tocline0"> 3. <a href="#header.fields">Header Field Definitions</a><ul class="toc">538 <li class="tocline1"> 3.1 <a href="#header.authorization">Authorization</a></li>539 <li class="tocline1"> 3.2 <a href="#header.proxy-authenticate">Proxy-Authenticate</a></li>540 <li class="tocline1"> 3.3 <a href="#header.proxy-authorization">Proxy-Authorization</a></li>541 <li class="tocline1"> 3.4 <a href="#header.www-authenticate">WWW-Authenticate</a></li>541 <li class="tocline0">4. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 542 <li class="tocline1">4.1 <a href="#header.authorization">Authorization</a></li> 543 <li class="tocline1">4.2 <a href="#header.proxy-authenticate">Proxy-Authenticate</a></li> 544 <li class="tocline1">4.3 <a href="#header.proxy-authorization">Proxy-Authorization</a></li> 545 <li class="tocline1">4.4 <a href="#header.www-authenticate">WWW-Authenticate</a></li> 542 546 </ul> 543 547 </li> 544 <li class="tocline0"> 4. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc">545 <li class="tocline1"> 4.1 <a href="#status.code.registration">Status Code Registration</a></li>546 <li class="tocline1"> 4.2 <a href="#header.field.registration">Header Field Registration</a></li>548 <li class="tocline0">5. <a href="#IANA.considerations">IANA Considerations</a><ul class="toc"> 549 <li class="tocline1">5.1 <a href="#status.code.registration">Status Code Registration</a></li> 550 <li class="tocline1">5.2 <a href="#header.field.registration">Header Field Registration</a></li> 547 551 </ul> 548 552 </li> 549 <li class="tocline0"> 5. <a href="#security.considerations">Security Considerations</a><ul class="toc">550 <li class="tocline1"> 5.1 <a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li>553 <li class="tocline0">6. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 554 <li class="tocline1">6.1 <a href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></li> 551 555 </ul> 552 556 </li> 553 <li class="tocline0"> 6. <a href="#ack">Acknowledgments</a></li>554 <li class="tocline0"> 7. <a href="#rfc.references">References</a><ul class="toc">555 <li class="tocline1"> 7.1 <a href="#rfc.references.1">Normative References</a></li>556 <li class="tocline1"> 7.2 <a href="#rfc.references.2">Informative References</a></li>557 <li class="tocline0">7. <a href="#ack">Acknowledgments</a></li> 558 <li class="tocline0">8. <a href="#rfc.references">References</a><ul class="toc"> 559 <li class="tocline1">8.1 <a href="#rfc.references.1">Normative References</a></li> 560 <li class="tocline1">8.2 <a href="#rfc.references.2">Informative References</a></li> 557 561 </ul> 558 562 </li> … … 578 582 </ul> 579 583 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 580 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 access control and authentication. Right now it includes the extracted relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> with only minor changes. The intention is to move the general framework for HTTP authentication here, as currently specified 581 in <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, and allow the individual authentication mechanisms to be defined elsewhere. This introduction will be rewritten when that 582 occurs. 584 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 access control and authentication. It includes the relevant parts of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> with only minor changes, plus the general framework for HTTP authentication, as previously defined in "HTTP Authentication: 585 Basic and Digest Access Authentication" (<a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>). 583 586 </p> 584 587 <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to 585 provide authentication information. The general framework for access authentication, and the specification of "basic" and 586 "digest" authentication, are specified in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. This specification adopts the definitions of "challenge" and "credentials" from that specification. 588 provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>. 587 589 </p> 588 590 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 605 607 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 606 608 </p> 607 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, 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>> 608 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 609 <p id="rfc.section.1.2.2.p.1"> The ABNF rules below are defined in other specifications:</p> 610 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#abnf.dependencies" class="smpl">challenge</a> = <challenge, defined in <a href="#RFC2617" id="rfc.xref.RFC2617.3"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a>> 611 <a href="#abnf.dependencies" class="smpl">credentials</a> = <credentials, defined in <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, <a href="http://tools.ietf.org/html/rfc2617#section-1.2">Section 1.2</a>> 612 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> 613 <div id="rfc.iref.2"></div> 609 <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>> 610 <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>> 611 <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>> 612 </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> 613 <p id="rfc.section.2.p.1">HTTP provides a simple challenge-response authentication mechanism that can be used by a server to challenge a client request 614 and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication 615 scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication 616 via that scheme. 617 </p> 618 <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 = token 619 auth-param = token "=" ( token / quoted-string ) 620 </pre><p id="rfc.section.2.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. The 407 (Proxy 621 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. 622 </p> 623 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span> <a href="#access.authentication.framework" class="smpl">challenge</a> = <a href="#access.authentication.framework" class="smpl">auth-scheme</a> 1*<a href="#notation" class="smpl">SP</a> 1#<a href="#access.authentication.framework" class="smpl">auth-param</a> 624 </pre><div class="note" id="rfc.section.2.p.5"> 625 <p> <b>Note:</b> User agents will need to take special care in parsing the WWW-Authenticate or Proxy-Authenticate header field value if it 626 contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge 627 can itself contain a comma-separated list of authentication parameters. 628 </p> 629 </div> 630 <p id="rfc.section.2.p.6">The authentication parameter realm is defined for all authentication schemes:</p> 631 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.r.1"></span><span id="rfc.iref.r.2"></span> realm = "realm" "=" realm-value 632 realm-value = quoted-string 633 </pre><p id="rfc.section.2.p.8">The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value 634 (case-sensitive), in combination with the canonical root URL ( the scheme and authority components of the effective request 635 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, defines the protection space. These realms allow the protected resources on a server to be 636 partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm 637 value is a string, generally assigned by the origin server, which can have additional semantics specific to the authentication 638 scheme. Note that there can be multiple challenges with the same auth-scheme but different realms. 639 </p> 640 <p id="rfc.section.2.p.9">A user agent that wishes to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 641 (Unauthorized) -- <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy 642 -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) -- <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization 643 field value consist of credentials containing the authentication information of the client for the realm of the resource being 644 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 645 upon that challenge. 646 </p> 647 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.c.2"></span> <a href="#access.authentication.framework" class="smpl">credentials</a> = <a href="#access.authentication.framework" class="smpl">auth-scheme</a> ( <a href="#core.rules" class="smpl">token</a> 648 / <a href="#core.rules" class="smpl">quoted-string</a> 649 / #<a href="#access.authentication.framework" class="smpl">auth-param</a> ) 650 </pre><div class="note" id="rfc.section.2.p.11"> 651 <p> <b>Note:</b> many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should only include 652 Basic if it is minimally acceptable.<span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: Either rephrase and add reference or drop.]</span> 653 </p> 654 </div> 655 <p id="rfc.section.2.p.12">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been 656 authorized, the same credentials <em class="bcp14">MAY</em> be reused for all other requests within that protection space for a period of time determined by the authentication scheme, 657 parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot 658 extend outside the scope of its server. 659 </p> 660 <p id="rfc.section.2.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. 661 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 662 resource. 663 </p> 664 <p id="rfc.section.2.p.14">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional 665 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 666 authentication information. However, these additional mechanisms are not defined by this specification. 667 </p> 668 <p id="rfc.section.2.p.15">Proxies <em class="bcp14">MUST</em> be completely transparent regarding user agent authentication by origin servers. That is, they <em class="bcp14">MUST</em> forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in <a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 4.1</a>. Both the Proxy-Authenticate and the Proxy-Authorization header fields are hop-by-hop headers (see <a href="p1-messaging.html#end-to-end.and.hop-by-hop.header-fields" title="End-to-end and Hop-by-hop Header Fields">Section 7.1.3.1</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>). 669 </p> 670 <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> 671 <div id="rfc.iref.6"></div> 614 672 <div id="rfc.iref.s.1"></div> 615 <h2 id="rfc.section. 2.1"><a href="#rfc.section.2.1">2.1</a> <a id="status.401" href="#status.401">401 Unauthorized</a></h2>616 <p id="rfc.section. 2.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 3.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been673 <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> 674 <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 Authorization 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 617 675 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 618 676 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 619 information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.620 </p> 621 <div id="rfc.iref. 3"></div>677 information. 678 </p> 679 <div id="rfc.iref.7"></div> 622 680 <div id="rfc.iref.s.2"></div> 623 <h2 id="rfc.section. 2.2"><a href="#rfc.section.2.2">2.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>624 <p id="rfc.section. 2.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The625 proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 3.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.626 </p> 627 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>628 <p id="rfc.section. 3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to authentication.</p>629 <div id="rfc.iref.a. 1"></div>681 <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> 682 <p id="rfc.section.3.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client ought to first authenticate itself with the proxy. 683 The proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 4.3</a>). 684 </p> 685 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 686 <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to authentication.</p> 687 <div id="rfc.iref.a.3"></div> 630 688 <div id="rfc.iref.h.1"></div> 631 <h2 id="rfc.section. 3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2>632 <p id="rfc.section. 3.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server -- usually, but not necessarily,689 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 690 <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server -- usually, but not necessarily, 633 691 after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent 634 692 for the realm of the resource being requested. 635 693 </p> 636 <div id="rfc.figure.u. 3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#header.authorization" class="smpl">Authorization</a> = "Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.authorization" class="smpl">Authorization-v</a>637 <a href="#header.authorization" class="smpl">Authorization-v</a> = <a href="#a bnf.dependencies" class="smpl">credentials</a>638 </pre><p id="rfc.section. 3.1.p.3">HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.7"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.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,694 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#header.authorization" class="smpl">Authorization</a> = "Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.authorization" class="smpl">Authorization-v</a> 695 <a href="#header.authorization" class="smpl">Authorization-v</a> = <a href="#access.authentication.framework" class="smpl">credentials</a> 696 </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, 639 697 such as credentials that vary according to a challenge value or using synchronized clocks). 640 698 </p> 641 <p id="rfc.section. 3.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches">Section 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) receives a request containing an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:642 </p> 643 <p id="rfc.section. 3.1.p.5"> </p>699 <p id="rfc.section.4.1.p.4">When a shared cache (see <a href="p6-cache.html#shared.and.non-shared.caches">Section 1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) receives a request containing an Authorization field, it <em class="bcp14">MUST NOT</em> return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds: 700 </p> 701 <p id="rfc.section.4.1.p.5"> </p> 644 702 <ol> 645 703 <li>If the response includes the "s-maxage" cache-control directive, the cache <em class="bcp14">MAY</em> use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache <em class="bcp14">MUST</em> first revalidate it with the origin server, using the request-header fields from the new request to allow the origin server … … 654 712 <div id="rfc.iref.p.1"></div> 655 713 <div id="rfc.iref.h.2"></div> 656 <h2 id="rfc.section. 3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>657 <p id="rfc.section. 3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters658 applicable 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. 4"><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.659 </p> 660 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a>714 <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> 715 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters 716 applicable 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. 717 </p> 718 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> 661 719 <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate-v</a> 662 <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate-v</a> = 1#<a href="#a bnf.dependencies" class="smpl">challenge</a>663 </pre><p id="rfc.section. 3.2.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.8"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.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 requesting720 <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate-v</a> = 1#<a href="#access.authentication.framework" class="smpl">challenge</a> 721 </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 664 722 them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate 665 723 header field. … … 667 725 <div id="rfc.iref.p.2"></div> 668 726 <div id="rfc.iref.h.3"></div> 669 <h2 id="rfc.section. 3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>670 <p id="rfc.section. 3.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires727 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2> 728 <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires 671 729 authentication. Its value consists of credentials containing the authentication information of the user agent for the proxy 672 730 and/or realm of the resource being requested. 673 731 </p> 674 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a>732 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> 675 733 <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization-v</a> 676 <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization-v</a> = <a href="#a bnf.dependencies" class="smpl">credentials</a>677 </pre><p id="rfc.section. 3.3.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.9"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication734 <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization-v</a> = <a href="#access.authentication.framework" class="smpl">credentials</a> 735 </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 678 736 using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed 679 737 by the first outbound proxy 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 … … 682 740 <div id="rfc.iref.w.1"></div> 683 741 <div id="rfc.iref.h.4"></div> 684 <h2 id="rfc.section. 3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>685 <p id="rfc.section. 3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)686 and parameters 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. 5"><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.687 </p> 688 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>689 <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> = 1#<a href="#a bnf.dependencies" class="smpl">challenge</a>690 </pre><p id="rfc.section. 3.4.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.10"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one742 <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> 743 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s) 744 and parameters 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. 745 </p> 746 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> 747 <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> = 1#<a href="#access.authentication.framework" class="smpl">challenge</a> 748 </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 one 691 749 challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a 692 750 comma-separated list of authentication parameters. 693 751 </p> 694 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>695 <h2 id="rfc.section. 4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>696 <p id="rfc.section. 4.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below:752 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 753 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 754 <p id="rfc.section.5.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 697 755 </p> 698 756 <div id="rfc.table.1"> … … 710 768 <td class="left">401</td> 711 769 <td class="left">Unauthorized</td> 712 <td class="left"> <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 2.1</a>770 <td class="left"> <a href="#status.401" id="rfc.xref.status.401.1" title="401 Unauthorized">Section 3.1</a> 713 771 </td> 714 772 </tr> … … 716 774 <td class="left">407</td> 717 775 <td class="left">Proxy Authentication Required</td> 718 <td class="left"> <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 2.2</a>776 <td class="left"> <a href="#status.407" id="rfc.xref.status.407.1" title="407 Proxy Authentication Required">Section 3.2</a> 719 777 </td> 720 778 </tr> … … 722 780 </table> 723 781 </div> 724 <h2 id="rfc.section. 4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>725 <p id="rfc.section. 4.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):782 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 783 <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 726 784 </p> 727 785 <div id="rfc.table.2"> … … 741 799 <td class="left">http</td> 742 800 <td class="left">standard</td> 743 <td class="left"> <a href="#header.authorization" id="rfc.xref.header.authorization. 2" title="Authorization">Section 3.1</a>801 <td class="left"> <a href="#header.authorization" id="rfc.xref.header.authorization.3" title="Authorization">Section 4.1</a> 744 802 </td> 745 803 </tr> … … 748 806 <td class="left">http</td> 749 807 <td class="left">standard</td> 750 <td class="left"> <a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.2" title="Proxy-Authenticate">Section 3.2</a>808 <td class="left"> <a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.2" title="Proxy-Authenticate">Section 4.2</a> 751 809 </td> 752 810 </tr> … … 755 813 <td class="left">http</td> 756 814 <td class="left">standard</td> 757 <td class="left"> <a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.2" title="Proxy-Authorization">Section 3.3</a>815 <td class="left"> <a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.2" title="Proxy-Authorization">Section 4.3</a> 758 816 </td> 759 817 </tr> … … 762 820 <td class="left">http</td> 763 821 <td class="left">standard</td> 764 <td class="left"> <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section 3.4</a>822 <td class="left"> <a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.2" title="WWW-Authenticate">Section 4.4</a> 765 823 </td> 766 824 </tr> … … 768 826 </table> 769 827 </div> 770 <p id="rfc.section. 4.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>771 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>772 <p id="rfc.section. 5.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1828 <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 829 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 830 <p id="rfc.section.6.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 773 831 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 774 832 make some suggestions for reducing security risks. 775 833 </p> 776 <h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> <a id="auth.credentials.and.idle.clients" href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></h2>777 <p id="rfc.section. 5.1.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1 does not provide834 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="auth.credentials.and.idle.clients" href="#auth.credentials.and.idle.clients">Authentication Credentials and Idle Clients</a></h2> 835 <p id="rfc.section.6.1.p.1">Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1 does not provide 778 836 a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further 779 837 extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include … … 788 846 </li> 789 847 </ul> 790 <p id="rfc.section. 5.1.p.2">This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the848 <p id="rfc.section.6.1.p.2">This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the 791 849 use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent 792 850 in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism 793 851 for discarding cached credentials under user control. 794 852 </p> 795 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 796 <p id="rfc.section.6.p.1"> <span class="comment" id="acks">[<a href="#acks" class="smpl">acks</a>: TBD.]</span> 797 </p> 798 <h1 id="rfc.references"><a id="rfc.section.7" href="#rfc.section.7">7.</a> References 853 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 854 <p id="rfc.section.7.p.1">This specification takes over the definition of the HTTP Authentication Framework, previously defined in <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">RFC 2617</cite>. We thank to John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, 855 and Lawrence C. Stewart for their work on that specification. 856 </p> 857 <p id="rfc.section.7.p.2"> <span class="comment" id="acks">[<a href="#acks" class="smpl">acks</a>: HTTPbis acknowledgements.]</span> 858 </p> 859 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References 799 860 </h1> 800 <h2 id="rfc.references.1"><a href="#rfc.section. 7.1" id="rfc.section.7.1">7.1</a> Normative References861 <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References 801 862 </h2> 802 <table> 863 <table> 803 864 <tr> 804 865 <td class="reference"><b id="Part1">[Part1]</b></td> … … 817 878 </tr> 818 879 <tr> 819 <td class="reference"><b id="RFC2617">[RFC2617]</b></td>820 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999.821 </td>822 </tr>823 <tr>824 880 <td class="reference"><b id="RFC5234">[RFC5234]</b></td> 825 881 <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD 68, RFC 5234, January 2008. … … 827 883 </tr> 828 884 </table> 829 <h2 id="rfc.references.2"><a href="#rfc.section. 7.2" id="rfc.section.7.2">7.2</a> Informative References885 <h2 id="rfc.references.2"><a href="#rfc.section.8.2" id="rfc.section.8.2">8.2</a> Informative References 830 886 </h2> 831 <table> 887 <table> 832 888 <tr> 833 889 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 834 890 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 891 </td> 892 </tr> 893 <tr> 894 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 895 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. 835 896 </td> 836 897 </tr> … … 860 921 </div> 861 922 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 862 <div id="rfc.figure.u. 7"></div> <pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = "Authorization:" OWS Authorization-v923 <div id="rfc.figure.u.10"></div> <pre class="inline"><a href="#header.authorization" class="smpl">Authorization</a> = "Authorization:" OWS Authorization-v 863 924 <a href="#header.authorization" class="smpl">Authorization-v</a> = credentials 864 925 … … 876 937 challenge ] ) 877 938 878 <a href="#abnf.dependencies" class="smpl">challenge</a> = <challenge, defined in [RFC2617], Section 1.2> 879 <a href="#abnf.dependencies" class="smpl">credentials</a> = <credentials, defined in [RFC2617], Section 1.2> 880 </pre> <div id="rfc.figure.u.8"></div> 939 <a href="#access.authentication.framework" class="smpl">auth-param</a> = token "=" ( token / quoted-string ) 940 <a href="#access.authentication.framework" class="smpl">auth-scheme</a> = token 941 942 <a href="#access.authentication.framework" class="smpl">challenge</a> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS 943 auth-param ] ) 944 <a href="#access.authentication.framework" class="smpl">credentials</a> = auth-scheme ( token / quoted-string / [ ( "," / 945 auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) 946 947 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 1.2.2> 948 949 realm = "realm=" realm-value 950 realm-value = quoted-string 951 952 <a href="#core.rules" class="smpl">token</a> = <token, defined in [Part1], Section 1.2.2> 953 </pre> <div id="rfc.figure.u.11"></div> 881 954 <p>ABNF diagnostics:</p><pre class="inline">; Authorization defined but not used 882 955 ; Proxy-Authenticate defined but not used 883 956 ; Proxy-Authorization defined but not used 884 957 ; WWW-Authenticate defined but not used 958 ; realm defined but not used 885 959 </pre><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 886 960 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Since RFC2616 887 961 </h2> 888 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.962 <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 889 963 </p> 890 964 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Since draft-ietf-httpbis-p7-auth-00 … … 943 1017 <p id="rfc.section.B.12.p.1">None yet.</p> 944 1018 <h2 id="rfc.section.B.13"><a href="#rfc.section.B.13">B.13</a> <a id="changes.since.11" href="#changes.since.11">Since draft-ietf-httpbis-p7-auth-11</a></h2> 945 <p id="rfc.section.B.13.p.1">None yet.</p> 1019 <p id="rfc.section.B.13.p.1">Closed issues: </p> 1020 <ul> 1021 <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" 1022 </li> 1023 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/237">http://tools.ietf.org/wg/httpbis/trac/ticket/237</a>>: "absorbing the auth framework from 2617" 1024 </li> 1025 </ul> 946 1026 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 947 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</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>1027 <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> 948 1028 </p> 949 1029 <div class="print2col"> 950 1030 <ul class="ind"> 951 1031 <li class="indline0"><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul class="ind"> 952 <li class="indline1">401 Unauthorized (status code) <a class="iref" href="#rfc.iref. 2"><b>2.1</b></a>, <a class="iref" href="#rfc.xref.status.401.1">4.1</a></li>953 <li class="indline1">407 Proxy Authentication Required (status code) <a class="iref" href="#rfc.iref. 3"><b>2.2</b></a>, <a class="iref" href="#rfc.xref.status.407.1">4.1</a></li>1032 <li class="indline1">401 Unauthorized (status code) <a class="iref" href="#rfc.iref.6"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.status.401.1">5.1</a></li> 1033 <li class="indline1">407 Proxy Authentication Required (status code) <a class="iref" href="#rfc.iref.7"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.status.407.1">5.1</a></li> 954 1034 </ul> 955 1035 </li> 956 1036 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 957 <li class="indline1">Authorization header <a class="iref" href="#rfc.xref.header.authorization.1">2.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.authorization.2">4.2</a></li> 1037 <li class="indline1"><tt>auth-param</tt> <a class="iref" href="#rfc.iref.a.2"><b>2</b></a></li> 1038 <li class="indline1"><tt>auth-scheme</tt> <a class="iref" href="#rfc.iref.a.1"><b>2</b></a></li> 1039 <li class="indline1">Authorization header <a class="iref" href="#rfc.xref.header.authorization.1">2</a>, <a class="iref" href="#rfc.xref.header.authorization.2">3.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.authorization.3">5.2</a></li> 1040 </ul> 1041 </li> 1042 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 1043 <li class="indline1"><tt>challenge</tt> <a class="iref" href="#rfc.iref.c.1"><b>2</b></a></li> 1044 <li class="indline1"><tt>credentials</tt> <a class="iref" href="#rfc.iref.c.2"><b>2</b></a></li> 958 1045 </ul> 959 1046 </li> … … 961 1048 <li class="indline1"><tt>Grammar</tt> 962 1049 <ul class="ind"> 963 <li class="indline1"><tt>Authorization</tt> <a class="iref" href="#rfc.iref.g.3"><b>3.1</b></a></li> 964 <li class="indline1"><tt>Authorization-v</tt> <a class="iref" href="#rfc.iref.g.4"><b>3.1</b></a></li> 965 <li class="indline1"><tt>challenge</tt> <a class="iref" href="#rfc.iref.g.1"><b>1.2.2</b></a></li> 966 <li class="indline1"><tt>credentials</tt> <a class="iref" href="#rfc.iref.g.2"><b>1.2.2</b></a></li> 967 <li class="indline1"><tt>Proxy-Authenticate</tt> <a class="iref" href="#rfc.iref.g.5"><b>3.2</b></a></li> 968 <li class="indline1"><tt>Proxy-Authenticate-v</tt> <a class="iref" href="#rfc.iref.g.6"><b>3.2</b></a></li> 969 <li class="indline1"><tt>Proxy-Authorization</tt> <a class="iref" href="#rfc.iref.g.7"><b>3.3</b></a></li> 970 <li class="indline1"><tt>Proxy-Authorization-v</tt> <a class="iref" href="#rfc.iref.g.8"><b>3.3</b></a></li> 971 <li class="indline1"><tt>WWW-Authenticate</tt> <a class="iref" href="#rfc.iref.g.9"><b>3.4</b></a></li> 972 <li class="indline1"><tt>WWW-Authenticate-v</tt> <a class="iref" href="#rfc.iref.g.10"><b>3.4</b></a></li> 1050 <li class="indline1"><tt>Authorization</tt> <a class="iref" href="#rfc.iref.g.1"><b>4.1</b></a></li> 1051 <li class="indline1"><tt>Authorization-v</tt> <a class="iref" href="#rfc.iref.g.2"><b>4.1</b></a></li> 1052 <li class="indline1"><tt>Proxy-Authenticate</tt> <a class="iref" href="#rfc.iref.g.3"><b>4.2</b></a></li> 1053 <li class="indline1"><tt>Proxy-Authenticate-v</tt> <a class="iref" href="#rfc.iref.g.4"><b>4.2</b></a></li> 1054 <li class="indline1"><tt>Proxy-Authorization</tt> <a class="iref" href="#rfc.iref.g.5"><b>4.3</b></a></li> 1055 <li class="indline1"><tt>Proxy-Authorization-v</tt> <a class="iref" href="#rfc.iref.g.6"><b>4.3</b></a></li> 1056 <li class="indline1"><tt>WWW-Authenticate</tt> <a class="iref" href="#rfc.iref.g.7"><b>4.4</b></a></li> 1057 <li class="indline1"><tt>WWW-Authenticate-v</tt> <a class="iref" href="#rfc.iref.g.8"><b>4.4</b></a></li> 973 1058 </ul> 974 1059 </li> … … 978 1063 <li class="indline1">Headers 979 1064 <ul class="ind"> 980 <li class="indline1">Authorization <a class="iref" href="#rfc.xref.header.authorization.1">2 .1</a>, <a class="iref" href="#rfc.iref.h.1"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.authorization.2">4.2</a></li>981 <li class="indline1">Proxy-Authenticate <a class="iref" href="#rfc.xref.header.proxy-authenticate.1"> 2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authenticate.2">4.2</a></li>982 <li class="indline1">Proxy-Authorization <a class="iref" href="#rfc.xref.header.proxy-authorization.1"> 2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authorization.2">4.2</a></li>983 <li class="indline1">WWW-Authenticate <a class="iref" href="#rfc.xref.header.www-authenticate.1"> 2.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.www-authenticate.2">4.2</a></li>1065 <li class="indline1">Authorization <a class="iref" href="#rfc.xref.header.authorization.1">2</a>, <a class="iref" href="#rfc.xref.header.authorization.2">3.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>4.1</b></a>, <a class="iref" href="#rfc.xref.header.authorization.3">5.2</a></li> 1066 <li class="indline1">Proxy-Authenticate <a class="iref" href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authenticate.2">5.2</a></li> 1067 <li class="indline1">Proxy-Authorization <a class="iref" href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authorization.2">5.2</a></li> 1068 <li class="indline1">WWW-Authenticate <a class="iref" href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.www-authenticate.2">5.2</a></li> 984 1069 </ul> 985 1070 </li> … … 987 1072 </li> 988 1073 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 989 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4"> 3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a>, <a class="iref" href="#Part1"><b>7.1</b></a><ul class="ind">1074 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">4.4</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 990 1075 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.2</a></li> 991 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a></li> 992 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.4">3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a></li> 1076 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a></li> 1077 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.8">4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">4.4</a></li> 1078 <li class="indline1"><em>Section 7.1.3.1</em> <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 993 1079 </ul> 994 1080 </li> 995 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 3.1</a>, <a class="iref" href="#Part6"><b>7.1</b></a><ul class="ind">996 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part6.1"> 3.1</a></li>1081 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">4.1</a>, <a class="iref" href="#Part6"><b>8.1</b></a><ul class="ind"> 1082 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part6.1">4.1</a></li> 997 1083 </ul> 998 1084 </li> 999 <li class="indline1">Proxy-Authenticate header <a class="iref" href="#rfc.xref.header.proxy-authenticate.1"> 2.2</a>, <a class="iref" href="#rfc.iref.p.1"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authenticate.2">4.2</a></li>1000 <li class="indline1">Proxy-Authorization header <a class="iref" href="#rfc.xref.header.proxy-authorization.1"> 2.2</a>, <a class="iref" href="#rfc.iref.p.2"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authorization.2">4.2</a></li>1085 <li class="indline1">Proxy-Authenticate header <a class="iref" href="#rfc.xref.header.proxy-authenticate.1">3.2</a>, <a class="iref" href="#rfc.iref.p.1"><b>4.2</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authenticate.2">5.2</a></li> 1086 <li class="indline1">Proxy-Authorization header <a class="iref" href="#rfc.xref.header.proxy-authorization.1">3.2</a>, <a class="iref" href="#rfc.iref.p.2"><b>4.3</b></a>, <a class="iref" href="#rfc.xref.header.proxy-authorization.2">5.2</a></li> 1001 1087 </ul> 1002 1088 </li> 1003 1089 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1004 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>7.1</b></a></li> 1005 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 1006 <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">1</a>, <a class="iref" href="#rfc.xref.RFC2617.2">1</a>, <a class="iref" href="#rfc.xref.RFC2617.3">1.2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.4">1.2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.5">2.1</a>, <a class="iref" href="#rfc.xref.RFC2617.6">2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.7">3.1</a>, <a class="iref" href="#rfc.xref.RFC2617.8">3.2</a>, <a class="iref" href="#rfc.xref.RFC2617.9">3.3</a>, <a class="iref" href="#rfc.xref.RFC2617.10">3.4</a>, <a class="iref" href="#RFC2617"><b>7.1</b></a><ul class="ind"> 1007 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.RFC2617.3">1.2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.4">1.2.2</a></li> 1008 </ul> 1009 </li> 1010 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">4.2</a>, <a class="iref" href="#RFC3864"><b>7.2</b></a></li> 1011 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a>, <a class="iref" href="#RFC5234"><b>7.1</b></a><ul class="ind"> 1090 <li class="indline1"><tt>realm</tt> <a class="iref" href="#rfc.iref.r.1"><b>2</b></a></li> 1091 <li class="indline1"><tt>realm-value</tt> <a class="iref" href="#rfc.iref.r.2"><b>2</b></a></li> 1092 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>8.1</b></a></li> 1093 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">7</a>, <a class="iref" href="#RFC2616"><b>8.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">B.1</a></li> 1094 <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">1</a>, <a class="iref" href="#rfc.xref.RFC2617.2">1</a>, <a class="iref" href="#RFC2617"><b>8.2</b></a></li> 1095 <li class="indline1"><em>RFC3864</em> <a class="iref" href="#rfc.xref.RFC3864.1">5.2</a>, <a class="iref" href="#RFC3864"><b>8.2</b></a></li> 1096 <li class="indline1"><em>RFC5234</em> <a class="iref" href="#rfc.xref.RFC5234.1">1.2</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a>, <a class="iref" href="#RFC5234"><b>8.1</b></a><ul class="ind"> 1012 1097 <li class="indline1"><em>Appendix B.1</em> <a class="iref" href="#rfc.xref.RFC5234.2">1.2</a></li> 1013 1098 </ul> … … 1018 1103 <li class="indline1">Status Codes 1019 1104 <ul class="ind"> 1020 <li class="indline1">401 Unauthorized <a class="iref" href="#rfc.iref.s.1"><b> 2.1</b></a>, <a class="iref" href="#rfc.xref.status.401.1">4.1</a></li>1021 <li class="indline1">407 Proxy Authentication Required <a class="iref" href="#rfc.iref.s.2"><b> 2.2</b></a>, <a class="iref" href="#rfc.xref.status.407.1">4.1</a></li>1105 <li class="indline1">401 Unauthorized <a class="iref" href="#rfc.iref.s.1"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.status.401.1">5.1</a></li> 1106 <li class="indline1">407 Proxy Authentication Required <a class="iref" href="#rfc.iref.s.2"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.status.407.1">5.1</a></li> 1022 1107 </ul> 1023 1108 </li> … … 1025 1110 </li> 1026 1111 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 1027 <li class="indline1">WWW-Authenticate header <a class="iref" href="#rfc.xref.header.www-authenticate.1"> 2.1</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.www-authenticate.2">4.2</a></li>1112 <li class="indline1">WWW-Authenticate header <a class="iref" href="#rfc.xref.header.www-authenticate.1">3.1</a>, <a class="iref" href="#rfc.iref.w.1"><b>4.4</b></a>, <a class="iref" href="#rfc.xref.header.www-authenticate.2">5.2</a></li> 1028 1113 </ul> 1029 1114 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r994 r998 19 19 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY effective-request-uri "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY end-to-end.and-hop-by-hop "<xref target='Part1' x:rel='#end-to-end.and.hop-by-hop.header-fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 22 <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 23 ]> … … 207 208 <section title="Introduction" anchor="introduction"> 208 209 <t> 209 This document defines HTTP/1.1 access control and authentication. Right now it 210 includes the extracted relevant sections of 211 <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor changes. 212 The intention is to move the general framework for HTTP authentication here, 213 as currently specified in <xref target="RFC2617"/>, and allow the individual 214 authentication mechanisms to be defined elsewhere. This introduction will 215 be rewritten when that occurs. 210 This document defines HTTP/1.1 access control and authentication. It 211 includes the relevant parts of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> 212 with only minor changes, plus the general framework for HTTP authentication, 213 as previously defined in "HTTP Authentication: Basic and Digest Access 214 Authentication" (<xref target="RFC2617"/>). 216 215 </t> 217 216 <t> 218 217 HTTP provides several &OPTIONAL; challenge-response authentication 219 mechanisms which can be used by a server to challenge a client 220 request and by a client to provide authentication information. The 221 general framework for access authentication, and the specification of 222 "basic" and "digest" authentication, are specified in "HTTP 223 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. This 224 specification adopts the definitions of "challenge" and "credentials" 225 from that specification. 218 mechanisms which can be used by a server to challenge a client request and 219 by a client to provide authentication information. The "basic" and "digest" 220 authentication schemes continue to be specified in 221 <xref target="RFC2617" x:fmt="none">RFC 2617</xref>. 226 222 </t> 227 223 … … 250 246 <x:anchor-alias value="OCTET"/> 251 247 <x:anchor-alias value="VCHAR"/> 248 <x:anchor-alias value="SP"/> 252 249 <x:anchor-alias value="WSP"/> 253 250 <t> … … 269 266 270 267 <section title="Core Rules" anchor="core.rules"> 271 <x:anchor-alias value="OWS"/> 272 <t> 273 The core rules below are defined in &basic-rules;: 268 <x:anchor-alias value="quoted-string"/> 269 <x:anchor-alias value="token"/> 270 <x:anchor-alias value="OWS"/> 271 <t> 272 The core rules below are defined in &basic-rules;: 274 273 </t> 275 274 <figure><artwork type="abnf2616"> 276 <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> 275 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &basic-rules;> 276 <x:ref>token</x:ref> = <token, defined in &basic-rules;> 277 <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> 277 278 </artwork></figure> 278 279 </section> 279 280 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies"> 280 </section> 281 </section> 282 283 <section title="Access Authentication Framework" anchor="access.authentication.framework"> 284 <x:anchor-alias value="auth-scheme"/> 285 <x:anchor-alias value="auth-param"/> 281 286 <x:anchor-alias value="challenge"/> 282 287 <x:anchor-alias value="credentials"/> 283 288 <t> 284 <x:anchor-alias value="OWS"/> 285 The ABNF rules below are defined in other specifications: 286 </t> 287 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="challenge"/><iref primary="true" item="Grammar" subitem="credentials"/> 288 <x:ref>challenge</x:ref> = <challenge, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>> 289 <x:ref>credentials</x:ref> = <credentials, defined in <xref target="RFC2617" x:fmt="," x:sec="1.2"/>> 289 HTTP provides a simple challenge-response authentication mechanism 290 that can be used by a server to challenge a client request and by a 291 client to provide authentication information. It uses an extensible, 292 case-insensitive token to identify the authentication scheme, 293 followed by a comma-separated list of attribute-value pairs which 294 carry the parameters necessary for achieving authentication via that 295 scheme. 296 </t> 297 <figure><artwork type="abnf2616"><iref item="auth-scheme" primary="true"/><iref item="auth-param" primary="true"/> 298 auth-scheme = token 299 auth-param = token "=" ( token / quoted-string ) 290 300 </artwork></figure> 291 </section> 292 293 </section> 294 295 </section> 296 301 <t> 302 The 401 (Unauthorized) response message is used by an origin server 303 to challenge the authorization of a user agent. This response &MUST; 304 include a WWW-Authenticate header field containing at least one 305 challenge applicable to the requested resource. The 407 (Proxy 306 Authentication Required) response message is used by a proxy to 307 challenge the authorization of a client and &MUST; include a Proxy-Authenticate 308 header field containing at least one challenge 309 applicable to the proxy for the requested resource. 310 </t> 311 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/> 312 <x:ref>challenge</x:ref> = <x:ref>auth-scheme</x:ref> 1*<x:ref>SP</x:ref> 1#<x:ref>auth-param</x:ref> 313 </artwork></figure> 314 <x:note> 315 <t> 316 <x:h>Note:</x:h> User agents will need to take special care in parsing the WWW-Authenticate 317 or Proxy-Authenticate header field value if it contains 318 more than one challenge, or if more than one WWW-Authenticate header 319 field is provided, since the contents of a challenge can itself 320 contain a comma-separated list of authentication parameters. 321 </t> 322 </x:note> 323 <t> 324 The authentication parameter realm is defined for all authentication 325 schemes: 326 </t> 327 <figure><artwork type="abnf2616"><iref item="realm" primary="true"/><iref item="realm-value" primary="true"/> 328 realm = "realm" "=" realm-value 329 realm-value = quoted-string 330 </artwork></figure> 331 <t> 332 The realm directive (case-insensitive) is required for all 333 authentication schemes that issue a challenge. The realm value 334 (case-sensitive), in combination with the canonical root URL ( 335 the scheme and authority components of the effective request URI; see <xref target="Part1" x:fmt="of" x:rel="#effective.request.uri"/>) of the server being accessed, defines the protection space. 336 These realms allow the protected resources on a server to be 337 partitioned into a set of protection spaces, each with its own 338 authentication scheme and/or authorization database. The realm value 339 is a string, generally assigned by the origin server, which can have 340 additional semantics specific to the authentication scheme. Note that 341 there can be multiple challenges with the same auth-scheme but 342 different realms. 343 </t> 344 <t> 345 A user agent that wishes to authenticate itself with an origin 346 server -- usually, but not necessarily, after receiving a 401 347 (Unauthorized) -- &MAY; do so by including an Authorization header field 348 with the request. A client that wishes to authenticate itself with a 349 proxy -- usually, but not necessarily, after receiving a 407 (Proxy 350 Authentication Required) -- &MAY; do so by including a Proxy-Authorization 351 header field with the request. Both the Authorization 352 field value and the Proxy-Authorization field value consist of 353 credentials containing the authentication information of the client 354 for the realm of the resource being requested. The user agent &MUST; 355 choose to use one of the challenges with the strongest auth-scheme it 356 understands and request credentials from the user based upon that 357 challenge. 358 </t> 359 <figure><artwork type="abnf2616"><iref item="credentials" primary="true"/> 360 <x:ref>credentials</x:ref> = <x:ref>auth-scheme</x:ref> ( <x:ref>token</x:ref> 361 / <x:ref>quoted-string</x:ref> 362 / #<x:ref>auth-param</x:ref> ) 363 </artwork></figure> 364 <x:note> 365 <t> 366 <x:h>Note:</x:h> many browsers will only recognize Basic and will require 367 that it be the first auth-scheme presented. Servers should only 368 include Basic if it is minimally acceptable.<cref>Either rephrase and add reference or drop.</cref> 369 </t> 370 </x:note> 371 <t> 372 The protection space determines the domain over which credentials can 373 be automatically applied. If a prior request has been authorized, the 374 same credentials &MAY; be reused for all other requests within that 375 protection space for a period of time determined by the 376 authentication scheme, parameters, and/or user preference. Unless 377 otherwise defined by the authentication scheme, a single protection 378 space cannot extend outside the scope of its server. 379 </t> 380 <t> 381 If the origin server does not wish to accept the credentials sent 382 with a request, it &SHOULD; return a 401 (Unauthorized) response. The 383 response &MUST; include a WWW-Authenticate header field containing at 384 least one (possibly new) challenge applicable to the requested 385 resource. If a proxy does not accept the credentials sent with a 386 request, it &SHOULD; return a 407 (Proxy Authentication Required). The 387 response &MUST; include a Proxy-Authenticate header field containing a 388 (possibly new) challenge applicable to the proxy for the requested 389 resource. 390 </t> 391 <t> 392 The HTTP protocol does not restrict applications to this simple 393 challenge-response mechanism for access authentication. Additional 394 mechanisms &MAY; be used, such as encryption at the transport level or 395 via message encapsulation, and with additional header fields 396 specifying authentication information. However, these additional 397 mechanisms are not defined by this specification. 398 </t> 399 <t> 400 Proxies &MUST; be completely transparent regarding user agent 401 authentication by origin servers. That is, they &MUST; forward the 402 WWW-Authenticate and Authorization headers untouched, and follow the 403 rules found in <xref target="header.authorization"/>. Both the Proxy-Authenticate and 404 the Proxy-Authorization header fields are hop-by-hop headers (see 405 &end-to-end.and-hop-by-hop;). 406 </t> 407 </section> 297 408 298 409 <section title="Status Code Definitions" anchor="status.code.definitions"> … … 311 422 authentication at least once, then the user &SHOULD; be presented the 312 423 representation that was given in the response, since that representation might 313 include relevant diagnostic information. HTTP access authentication 314 is explained in "HTTP Authentication: Basic and Digest Access 315 Authentication" <xref target="RFC2617"/>. 424 include relevant diagnostic information. 316 425 </t> 317 426 </section> … … 321 430 <t> 322 431 This code is similar to 401 (Unauthorized), but indicates that the 323 client mustfirst authenticate itself with the proxy. The proxy &MUST;432 client ought to first authenticate itself with the proxy. The proxy &MUST; 324 433 return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a 325 434 challenge applicable to the proxy for the target resource. The 326 435 client &MAY; repeat the request with a suitable Proxy-Authorization 327 header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained 328 in "HTTP Authentication: Basic and Digest Access Authentication" 329 <xref target="RFC2617"/>. 436 header field (<xref target="header.proxy-authorization"/>). 330 437 </t> 331 438 </section> … … 355 462 </artwork></figure> 356 463 <t> 357 HTTP access authentication is described in "HTTP Authentication: 358 Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is 464 If a request is 359 465 authenticated and a realm specified, the same credentials &SHOULD; 360 466 be valid for all other requests within this realm (assuming that … … 411 517 </artwork></figure> 412 518 <t> 413 The HTTP access authentication process is described in "HTTP 414 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 415 WWW-Authenticate, the Proxy-Authenticate header field applies only to 519 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to 416 520 the current connection and &SHOULD-NOT; be passed on to downstream 417 521 clients. However, an intermediate proxy might need to obtain its own … … 440 544 </artwork></figure> 441 545 <t> 442 The HTTP access authentication process is described in "HTTP 443 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. Unlike 444 Authorization, the Proxy-Authorization header field applies only to 546 Unlike Authorization, the Proxy-Authorization header field applies only to 445 547 the next outbound proxy that demanded authentication using the Proxy-Authenticate 446 548 field. When multiple proxies are used in a chain, the … … 469 571 </artwork></figure> 470 572 <t> 471 The HTTP access authentication process is described in "HTTP 472 Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>. User 473 agents are advised to take special care in parsing the WWW-Authenticate 573 User agents are advised to take special care in parsing the WWW-Authenticate 474 574 field value as it might contain more than one challenge, 475 575 or if more than one WWW-Authenticate header field is provided, the … … 597 697 <section title="Acknowledgments" anchor="ack"> 598 698 <t> 599 <cref anchor="acks">TBD.</cref> 699 This specification takes over the definition of the HTTP Authentication 700 Framework, previously defined in <xref target="RFC2616" x:fmt="none">RFC 2617</xref>. We thank to John Franks, 701 Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, 702 Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work 703 on that specification. 704 </t> 705 <t> 706 <cref anchor="acks">HTTPbis acknowledgements.</cref> 600 707 </t> 601 708 </section> … … 710 817 <seriesInfo name="BCP" value="14"/> 711 818 <seriesInfo name="RFC" value="2119"/> 712 </reference>713 714 <reference anchor="RFC2617">715 <front>716 <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>717 <author initials="J." surname="Franks" fullname="John Franks">718 <organization>Northwestern University, Department of Mathematics</organization>719 <address><email>john@math.nwu.edu</email></address>720 </author>721 <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">722 <organization>Verisign Inc.</organization>723 <address><email>pbaker@verisign.com</email></address>724 </author>725 <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">726 <organization>AbiSource, Inc.</organization>727 <address><email>jeff@AbiSource.com</email></address>728 </author>729 <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">730 <organization>Agranat Systems, Inc.</organization>731 <address><email>lawrence@agranat.com</email></address>732 </author>733 <author initials="P.J." surname="Leach" fullname="Paul J. Leach">734 <organization>Microsoft Corporation</organization>735 <address><email>paulle@microsoft.com</email></address>736 </author>737 <author initials="A." surname="Luotonen" fullname="Ari Luotonen">738 <organization>Netscape Communications Corporation</organization>739 </author>740 <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">741 <organization>Open Market, Inc.</organization>742 <address><email>stewart@OpenMarket.com</email></address>743 </author>744 <date month="June" year="1999"/>745 </front>746 <seriesInfo name="RFC" value="2617"/>747 819 </reference> 748 820 … … 808 880 </reference> 809 881 882 <reference anchor="RFC2617"> 883 <front> 884 <title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title> 885 <author initials="J." surname="Franks" fullname="John Franks"> 886 <organization>Northwestern University, Department of Mathematics</organization> 887 <address><email>john@math.nwu.edu</email></address> 888 </author> 889 <author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker"> 890 <organization>Verisign Inc.</organization> 891 <address><email>pbaker@verisign.com</email></address> 892 </author> 893 <author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler"> 894 <organization>AbiSource, Inc.</organization> 895 <address><email>jeff@AbiSource.com</email></address> 896 </author> 897 <author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence"> 898 <organization>Agranat Systems, Inc.</organization> 899 <address><email>lawrence@agranat.com</email></address> 900 </author> 901 <author initials="P.J." surname="Leach" fullname="Paul J. Leach"> 902 <organization>Microsoft Corporation</organization> 903 <address><email>paulle@microsoft.com</email></address> 904 </author> 905 <author initials="A." surname="Luotonen" fullname="Ari Luotonen"> 906 <organization>Netscape Communications Corporation</organization> 907 </author> 908 <author initials="L." surname="Stewart" fullname="Lawrence C. Stewart"> 909 <organization>Open Market, Inc.</organization> 910 <address><email>stewart@OpenMarket.com</email></address> 911 </author> 912 <date month="June" year="1999"/> 913 </front> 914 <seriesInfo name="RFC" value="2617"/> 915 </reference> 916 810 917 <reference anchor='RFC3864'> 811 918 <front> … … 856 963 challenge ] ) 857 964 858 <x:ref>challenge</x:ref> = <challenge, defined in [RFC2617], Section 1.2> 859 <x:ref>credentials</x:ref> = <credentials, defined in [RFC2617], Section 1.2> 965 <x:ref>auth-param</x:ref> = token "=" ( token / quoted-string ) 966 <x:ref>auth-scheme</x:ref> = token 967 968 <x:ref>challenge</x:ref> = auth-scheme 1*SP *( "," OWS ) auth-param *( OWS "," [ OWS 969 auth-param ] ) 970 <x:ref>credentials</x:ref> = auth-scheme ( token / quoted-string / [ ( "," / 971 auth-param ) *( OWS "," [ OWS auth-param ] ) ] ) 972 973 <x:ref>quoted-string</x:ref> = <quoted-string, defined in [Part1], Section 1.2.2> 974 975 realm = "realm=" realm-value 976 realm-value = quoted-string 977 978 <x:ref>token</x:ref> = <token, defined in [Part1], Section 1.2.2> 860 979 </artwork> 861 980 </figure> … … 865 984 ; Proxy-Authorization defined but not used 866 985 ; WWW-Authenticate defined but not used 986 ; realm defined but not used 867 987 </artwork></figure></section> 868 988 <?ENDINC p7-auth.abnf-appendix ?> … … 993 1113 <section title="Since draft-ietf-httpbis-p7-auth-11" anchor="changes.since.11"> 994 1114 <t> 995 None yet. 1115 Closed issues: 1116 <list style="symbols"> 1117 <t> 1118 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/195"/>: 1119 "auth-param syntax" 1120 </t> 1121 <t> 1122 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/237"/>: 1123 "absorbing the auth framework from 2617" 1124 </t> 1125 </list> 996 1126 </t> 997 1127 </section>
Note: See TracChangeset
for help on using the changeset viewer.
