Ignore:
Timestamp:
25/05/14 13:57:58 (6 years ago)
Author:
julian.reschke@…
Message:

editorial fixes (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.html

    r2667 r2692  
    463463  }
    464464  @bottom-center {
    465        content: "Expires November 13, 2014";
     465       content: "Expires November 26, 2014";
    466466  }
    467467  @bottom-right {
     
    503503      <meta name="dct.creator" content="Reschke, J. F.">
    504504      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    505       <meta name="dct.issued" scheme="ISO8601" content="2014-05-12">
     505      <meta name="dct.issued" scheme="ISO8601" content="2014-05-25">
    506506      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    507507      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
     
    531531            <tr>
    532532               <td class="left">Intended status: Standards Track</td>
    533                <td class="right">May 12, 2014</td>
     533               <td class="right">May 25, 2014</td>
    534534            </tr>
    535535            <tr>
    536                <td class="left">Expires: November 13, 2014</td>
     536               <td class="left">Expires: November 26, 2014</td>
    537537               <td class="right"></td>
    538538            </tr>
     
    561561            in progress”.
    562562         </p>
    563          <p>This Internet-Draft will expire on November 13, 2014.</p>
     563         <p>This Internet-Draft will expire on November 26, 2014.</p>
    564564      </div>
    565565      <div id="rfc.copyrightnotice">
     
    662662            <p id="rfc.section.2.1.p.1">HTTP provides a simple challenge-response authentication framework that can be used by a server to challenge a client request
    663663               and by a client to provide authentication information. It uses a case-insensitive token as a means to identify the authentication
    664                scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can either be
     664               scheme, followed by additional information necessary for achieving authentication via that scheme. The latter can be either
    665665               a comma-separated list of parameters or a single sequence of characters capable of holding base64-encoded information.
    666666            </p>
     
    703703               that requires authentication <em class="bcp14">SHOULD</em> generate a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with at least one (possibly new) challenge applicable to the proxy.
    704704            </p>
    705             <p id="rfc.section.2.1.p.15">A server that receives valid credentials which are not adequate to gain access ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
     705            <p id="rfc.section.2.1.p.15">A server that receives valid credentials that are not adequate to gain access ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>).
    706706            </p>
    707707            <p id="rfc.section.2.1.p.16">HTTP does not restrict applications to this simple challenge-response framework for access authentication. Additional mechanisms
     
    719719            <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    720720               on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    721                database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
    722                to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but different realms.
     721               database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
     722               to the authentication scheme. Note that a response can have multiple challenges with the same auth-scheme but with different
     723               realms.
    723724            </p>
    724725            <p id="rfc.section.2.2.p.3">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
     
    748749            <div id="rfc.iref.8"></div>
    749750            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#status.407">407 Proxy Authentication Required</a></h2>
    750             <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.3</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.4</a>).
     751            <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.3</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.4</a>).
    751752            </p>
    752753         </div>
     
    832833         <div id="authentication.scheme.registry">
    833834            <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#authentication.scheme.registry">Authentication Scheme Registry</a></h2>
    834             <p id="rfc.section.5.1.p.1">The HTTP Authentication Scheme Registry defines the namespace for the authentication schemes in challenges and credentials.
    835                It will be created and maintained at (the suggested URI) &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
     835            <p id="rfc.section.5.1.p.1">The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes
     836               in challenges and credentials. It will has been created and is now maintained at &lt;<a href="http://www.iana.org/assignments/http-authschemes">http://www.iana.org/assignments/http-authschemes</a>&gt;.
    836837            </p>
    837838            <div id="authentication.scheme.registry.procedure">
     
    861862                  </li>
    862863                  <li>
    863                      <p>The authentication parameter "realm" is reserved for defining Protection Spaces as defined in <a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>. New schemes <em class="bcp14">MUST NOT</em> use it in a way incompatible with that definition.
     864                     <p>The authentication parameter "realm" is reserved for defining protection spaces as described in <a href="#protection.space" title="Protection Space (Realm)">Section&nbsp;2.2</a>. New schemes <em class="bcp14">MUST NOT</em> use it in a way incompatible with that definition.
    864865                     </p>
    865866                  </li>
    866867                  <li>
    867868                     <p>The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per
    868                         challenge or credential. New schemes thus ought to use the "auth-param" syntax instead, because otherwise future extensions
     869                        challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions
    869870                        will be impossible.
    870871                     </p>
    871872                  </li>
    872873                  <li>
    873                      <p>The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes.
     874                     <p>The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes.
    874875                        When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints
    875876                        ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients
     
    882883                  <li>
    883884                     <p>Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule
    884                         is preferable over "must-understand", because otherwise it will be hard to introduce new parameters in the presence of legacy
    885                         recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification",
     885                        is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of
     886                        legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification"
    886887                        or "use this registry").
    887888                     </p>
     
    892893                  </li>
    893894                  <li>
    894                      <p>The credentials carried in an <a href="#header.authorization" class="smpl">Authorization</a> header field are specific to the User Agent, and therefore have the same effect on HTTP caches as the "private" Cache-Control
    895                         response directive (<a href="p6-cache.html#cache-response-directive.private" title="private">Section 5.2.2.6</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>), within the scope of the request they appear in.
     895                     <p>The credentials carried in an <a href="#header.authorization" class="smpl">Authorization</a> header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" Cache-Control
     896                        response directive (<a href="p6-cache.html#cache-response-directive.private" title="private">Section 5.2.2.6</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>), within the scope of the request in which they appear.
    896897                     </p>
    897898                     <p>Therefore, new authentication schemes that choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
Note: See TracChangeset for help on using the changeset viewer.