Changeset 1736 for draft-ietf-httpbis/latest/p7-auth.xml

Timestamp:

Jul 8, 2012, 5:30:37 AM (7 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink header field definitions(P7)

File:

• draft-ietf-httpbis/latest/p7-auth.xml (modified) (14 diffs)

draft-ietf-httpbis/latest/p7-auth.xml

@@ -260 +260 @@
    The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    to challenge the authorization of a user agent. This response &MUST;
-   include a WWW-Authenticate header field containing at least one
+   include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
    challenge applicable to the requested resource.
 </t>
 <t>   
-   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
-   challenge the authorization of a client and &MUST; include a Proxy-Authenticate
-   header field containing at least one challenge
-   applicable to the proxy for the requested resource.
+   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
+   used by a proxy to challenge the authorization of a client and &MUST;
+   include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
+   one challenge applicable to the proxy for the requested resource.
 </t>
 <figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/>
@@ -275 +275 @@
   <t>
      &Note; User agents will need to take special care in parsing the
-     WWW-Authenticate and Proxy-Authenticate header field values because they
-     can contain more than one challenge, or if more than one of each is
-     provided, since the contents of a challenge can itself contain a
-     comma-separated list of authentication parameters.
+     <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>
+     header field values because they can contain more than one challenge, or
+     if more than one of each is provided, since the contents of a challenge
+     can itself contain a comma-separated list of authentication parameters.
   </t>
 </x:note>
@@ -291 +291 @@
    A user agent that wishes to authenticate itself with an origin server
    &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
-   &mdash; can do so by including an Authorization header field with the
+   &mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
    request.
 </t>
@@ -297 +297 @@
    A client that wishes to authenticate itself with a proxy &mdash; usually,
    but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
-   &mdash; can do so by including a Proxy-Authorization header field with the
+   &mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
    request.
 </t>
 <t>
-   Both the Authorization field value and the Proxy-Authorization field value
+   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    contain the client's credentials for the realm of the resource being
    requested, based upon a challenge received from the server (possibly at
@@ -316 +316 @@
    invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    when the authentication scheme requires more than one round trip), an origin
-   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST;
-   include a WWW-Authenticate header field containing at least one (possibly
-   new) challenge applicable to the requested resource.
+   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such
+   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
+   containing at least one (possibly new) challenge applicable to the
+   requested resource.
 </t>
 <t>
@@ -324 +325 @@
    credentials or contain invalid or partial credentials, a proxy &SHOULD;
    return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
-   &MUST; include a Proxy-Authenticate header field containing a (possibly
+   &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly
    new) challenge applicable to the proxy.
 </t>
@@ -340 +341 @@
 </t>
 <t>
-   Proxies &MUST; forward the WWW-Authenticate and Authorization headers
-   unmodified and follow the rules found in <xref target="header.authorization"/>.
+   Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
+   <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
+   found in <xref target="header.authorization"/>.
 </t>
 </section>
@@ -467 +469 @@
     <t>
       Authentication schemes need to document whether they are usable in
-      origin-server authentication (i.e., using WWW-Authenticate), and/or
-      proxy authentication (i.e., using Proxy-Authenticate).
+      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
+      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
     </t>
     </x:lt>
     <x:lt>
     <t>
-      The credentials carried in an Authorization header field are specific to
+      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
       the User Agent, and therefore have the same effect on HTTP caches as the
       "private" Cache-Control response directive, within the scope of the
@@ -480 +482 @@
     <t>
       Therefore, new authentication schemes which choose not to carry
-      credentials in the Authorization header (e.g., using a newly defined
-      header) will need to explicitly disallow caching, by mandating the use of
+      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
+      header field) will need to explicitly disallow caching, by mandating the use of
       either Cache-Control request directives (e.g., "no-store") or response
       directives (e.g., "private").
@@ -501 +503 @@
 <t>
    The request requires user authentication. The response &MUST; include a
-   WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
-   applicable to the target resource. The client &MAY; repeat the
-   request with a suitable Authorization header field (<xref target="header.authorization"/>). If
-   the request already included Authorization credentials, then the 401
-   response indicates that authorization has been refused for those
-   credentials. If the 401 response contains the same challenge as the
-   prior response, and the user agent has already attempted
+   <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
+   containing a challenge applicable to the target resource. The client &MAY;
+   repeat the request with a suitable <x:ref>Authorization</x:ref> header field
+   (<xref target="header.authorization"/>). If the request already included
+   Authorization credentials, then the 401 response indicates that authorization
+   has been refused for those credentials. If the 401 response contains the
+   same challenge as the prior response, and the user agent has already attempted
    authentication at least once, then the user &SHOULD; be presented the
    representation that was given in the response, since that representation might
@@ -520 +522 @@
    This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    client ought to first authenticate itself with the proxy. The proxy &MUST;
-   return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
+   return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    challenge applicable to the proxy for the target resource. The
-   client &MAY; repeat the request with a suitable Proxy-Authorization
+   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
    header field (<xref target="header.proxy-authorization"/>).
 </t>
@@ -601 +603 @@
 </artwork></figure>
 <t>
-   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
-   the current connection, and intermediaries &SHOULD-NOT;  forward it to
-   downstream clients. However, an intermediate proxy might need to obtain its
-   own credentials by requesting them from the downstream client, which in
-   some circumstances will appear as if the proxy is forwarding the
+   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
+   applies only to the current connection, and intermediaries &SHOULD-NOT;
+   forward it to downstream clients. However, an intermediate proxy might need
+   to obtain its own credentials by requesting them from the downstream client,
+   which in some circumstances will appear as if the proxy is forwarding the
    Proxy-Authenticate header field.
 </t>
 <t>
-   Note that the parsing considerations for WWW-Authenticate apply to this
-   header field as well; see <xref target="header.www-authenticate"/> for
-   details.
+   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
+   apply to this header field as well; see <xref target="header.www-authenticate"/>
+   for details.
 </t>
 </section>
@@ -630 +632 @@
 </artwork></figure>
 <t>
-   Unlike Authorization, the Proxy-Authorization header field applies only to
-   the next outbound proxy that demanded authentication using the Proxy-Authenticate
+   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field applies only to
+   the next outbound proxy that demanded authentication using the <x:ref>Proxy-Authenticate</x:ref>
    field. When multiple proxies are used in a chain, the
    Proxy-Authorization header field is consumed by the first outbound
@@ -828 +830 @@
   Possible mitigation strategies include restricting direct access to
   authentication credentials (i.e., not making the content of the
-  Authorization request header field available), and separating protection
+  <x:ref>Authorization</x:ref> request header field available), and separating protection
   spaces by using a different host name for each party.
 </t>