Ignore:
Timestamp:
Jul 8, 2012, 5:30:37 AM (7 years ago)
Author:
julian.reschke@…
Message:

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

File:
1 edited

Legend:

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

    r1726 r1736  
    260260   The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    261261   to challenge the authorization of a user agent. This response &MUST;
    262    include a WWW-Authenticate header field containing at least one
     262   include a <x:ref>WWW-Authenticate</x:ref> header field containing at least one
    263263   challenge applicable to the requested resource.
    264264</t>
    265265<t>   
    266    The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
    267    challenge the authorization of a client and &MUST; include a Proxy-Authenticate
    268    header field containing at least one challenge
    269    applicable to the proxy for the requested resource.
     266   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is
     267   used by a proxy to challenge the authorization of a client and &MUST;
     268   include a <x:ref>Proxy-Authenticate</x:ref> header field containing at least
     269   one challenge applicable to the proxy for the requested resource.
    270270</t>
    271271<figure><artwork type="abnf2616"><iref item="challenge" primary="true"/><iref primary="true" item="Grammar" subitem="challenge"/>
     
    275275  <t>
    276276     &Note; User agents will need to take special care in parsing the
    277      WWW-Authenticate and Proxy-Authenticate header field values because they
    278      can contain more than one challenge, or if more than one of each is
    279      provided, since the contents of a challenge can itself contain a
    280      comma-separated list of authentication parameters.
     277     <x:ref>WWW-Authenticate</x:ref> and <x:ref>Proxy-Authenticate</x:ref>
     278     header field values because they can contain more than one challenge, or
     279     if more than one of each is provided, since the contents of a challenge
     280     can itself contain a comma-separated list of authentication parameters.
    281281  </t>
    282282</x:note>
     
    291291   A user agent that wishes to authenticate itself with an origin server
    292292   &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
    293    &mdash; can do so by including an Authorization header field with the
     293   &mdash; can do so by including an <x:ref>Authorization</x:ref> header field with the
    294294   request.
    295295</t>
     
    297297   A client that wishes to authenticate itself with a proxy &mdash; usually,
    298298   but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
    299    &mdash; can do so by including a Proxy-Authorization header field with the
     299   &mdash; can do so by including a <x:ref>Proxy-Authorization</x:ref> header field with the
    300300   request.
    301301</t>
    302302<t>
    303    Both the Authorization field value and the Proxy-Authorization field value
     303   Both the <x:ref>Authorization</x:ref> field value and the <x:ref>Proxy-Authorization</x:ref> field value
    304304   contain the client's credentials for the realm of the resource being
    305305   requested, based upon a challenge received from the server (possibly at
     
    316316   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    317317   when the authentication scheme requires more than one round trip), an origin
    318    server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST;
    319    include a WWW-Authenticate header field containing at least one (possibly
    320    new) challenge applicable to the requested resource.
     318   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such
     319   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
     320   containing at least one (possibly new) challenge applicable to the
     321   requested resource.
    321322</t>
    322323<t>
     
    324325   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    325326   return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    326    &MUST; include a Proxy-Authenticate header field containing a (possibly
     327   &MUST; include a <x:ref>Proxy-Authenticate header</x:ref> field containing a (possibly
    327328   new) challenge applicable to the proxy.
    328329</t>
     
    340341</t>
    341342<t>
    342    Proxies &MUST; forward the WWW-Authenticate and Authorization headers
    343    unmodified and follow the rules found in <xref target="header.authorization"/>.
     343   Proxies &MUST; forward the <x:ref>WWW-Authenticate</x:ref> and
     344   <x:ref>Authorization</x:ref> header fields unmodified and follow the rules
     345   found in <xref target="header.authorization"/>.
    344346</t>
    345347</section>
     
    467469    <t>
    468470      Authentication schemes need to document whether they are usable in
    469       origin-server authentication (i.e., using WWW-Authenticate), and/or
    470       proxy authentication (i.e., using Proxy-Authenticate).
     471      origin-server authentication (i.e., using <x:ref>WWW-Authenticate</x:ref>),
     472      and/or proxy authentication (i.e., using <x:ref>Proxy-Authenticate</x:ref>).
    471473    </t>
    472474    </x:lt>
    473475    <x:lt>
    474476    <t>
    475       The credentials carried in an Authorization header field are specific to
     477      The credentials carried in an <x:ref>Authorization</x:ref> header field are specific to
    476478      the User Agent, and therefore have the same effect on HTTP caches as the
    477479      "private" Cache-Control response directive, within the scope of the
     
    480482    <t>
    481483      Therefore, new authentication schemes which choose not to carry
    482       credentials in the Authorization header (e.g., using a newly defined
    483       header) will need to explicitly disallow caching, by mandating the use of
     484      credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
     485      header field) will need to explicitly disallow caching, by mandating the use of
    484486      either Cache-Control request directives (e.g., "no-store") or response
    485487      directives (e.g., "private").
     
    501503<t>
    502504   The request requires user authentication. The response &MUST; include a
    503    WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge
    504    applicable to the target resource. The client &MAY; repeat the
    505    request with a suitable Authorization header field (<xref target="header.authorization"/>). If
    506    the request already included Authorization credentials, then the 401
    507    response indicates that authorization has been refused for those
    508    credentials. If the 401 response contains the same challenge as the
    509    prior response, and the user agent has already attempted
     505   <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
     506   containing a challenge applicable to the target resource. The client &MAY;
     507   repeat the request with a suitable <x:ref>Authorization</x:ref> header field
     508   (<xref target="header.authorization"/>). If the request already included
     509   Authorization credentials, then the 401 response indicates that authorization
     510   has been refused for those credentials. If the 401 response contains the
     511   same challenge as the prior response, and the user agent has already attempted
    510512   authentication at least once, then the user &SHOULD; be presented the
    511513   representation that was given in the response, since that representation might
     
    520522   This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    521523   client ought to first authenticate itself with the proxy. The proxy &MUST;
    522    return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
     524   return a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    523525   challenge applicable to the proxy for the target resource. The
    524    client &MAY; repeat the request with a suitable Proxy-Authorization
     526   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
    525527   header field (<xref target="header.proxy-authorization"/>).
    526528</t>
     
    601603</artwork></figure>
    602604<t>
    603    Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to
    604    the current connection, and intermediaries &SHOULD-NOT;  forward it to
    605    downstream clients. However, an intermediate proxy might need to obtain its
    606    own credentials by requesting them from the downstream client, which in
    607    some circumstances will appear as if the proxy is forwarding the
     605   Unlike <x:ref>WWW-Authenticate</x:ref>, the Proxy-Authenticate header field
     606   applies only to the current connection, and intermediaries &SHOULD-NOT;
     607   forward it to downstream clients. However, an intermediate proxy might need
     608   to obtain its own credentials by requesting them from the downstream client,
     609   which in some circumstances will appear as if the proxy is forwarding the
    608610   Proxy-Authenticate header field.
    609611</t>
    610612<t>
    611    Note that the parsing considerations for WWW-Authenticate apply to this
    612    header field as well; see <xref target="header.www-authenticate"/> for
    613    details.
     613   Note that the parsing considerations for <x:ref>WWW-Authenticate</x:ref>
     614   apply to this header field as well; see <xref target="header.www-authenticate"/>
     615   for details.
    614616</t>
    615617</section>
     
    630632</artwork></figure>
    631633<t>
    632    Unlike Authorization, the Proxy-Authorization header field applies only to
    633    the next outbound proxy that demanded authentication using the Proxy-Authenticate
     634   Unlike <x:ref>Authorization</x:ref>, the Proxy-Authorization header field applies only to
     635   the next outbound proxy that demanded authentication using the <x:ref>Proxy-Authenticate</x:ref>
    634636   field. When multiple proxies are used in a chain, the
    635637   Proxy-Authorization header field is consumed by the first outbound
     
    828830  Possible mitigation strategies include restricting direct access to
    829831  authentication credentials (i.e., not making the content of the
    830   Authorization request header field available), and separating protection
     832  <x:ref>Authorization</x:ref> request header field available), and separating protection
    831833  spaces by using a different host name for each party.
    832834</t>
Note: See TracChangeset for help on using the changeset viewer.