credentials = auth-scheme #auth-param

      Note that many browsers will only recognize Basic and will require
      that it be the first auth-scheme presented. Servers should only
      include Basic if it is minimally acceptable.

   The protection space determines the domain over which credentials can
   be automatically applied. If a prior request has been authorized, the
   same credentials MAY be reused for all other requests within that
   protection space for a period of time determined by the
   authentication scheme, parameters, and/or user preference. Unless
   otherwise defined by the authentication scheme, a single protection
   space cannot extend outside the scope of its server.

   If the origin server does not wish to accept the credentials sent
   with a request, it SHOULD return a 401 (Unauthorized) response. The
   response MUST include a WWW-Authenticate header field containing at
   least one (possibly new) challenge applicable to the requested
   resource. If a proxy does not accept the credentials sent with a
   request, it SHOULD return a 407 (Proxy Authentication Required). The
   response MUST include a Proxy-Authenticate header field containing a




 
RFC 2617                  HTTP Authentication                  June 1999


   (possibly new) challenge applicable to the proxy for the requested
   resource.

   The HTTP protocol does not restrict applications to this simple
   challenge-response mechanism for access authentication. Additional
   mechanisms MAY be used, such as encryption at the transport level or
   via message encapsulation, and with additional header fields
   specifying authentication information. However, these additional
   mechanisms are not defined by this specification.

   Proxies MUST be completely transparent regarding user agent
   authentication by origin servers. That is, they must forward the
   WWW-Authenticate and Authorization headers untouched, and follow the
   rules found in section 14.8 of [2]. Both the Proxy-Authenticate and
   the Proxy-Authorization header fields are hop-by-hop headers (see
   section 13.5.1 of [2]).

2 Basic Authentication Scheme

   The "basic" authentication scheme is based on the model that the
   client must authenticate itself with a user-ID and a password for
   each realm.  The realm value should be considered an opaque string
   which can only be compared for equality with other realms on that
   server. The server will service the request only if it can validate
   the user-ID and password for the protection space of the Request-URI.
   There are no optional authentication parameters.

   For Basic, the framework above is utilized as follows:

      challenge   = "Basic" realm
      credentials = "Basic" basic-credentials

   Upon receipt of an unauthorized request for a URI within the
   protection space, the origin server MAY respond with a challenge like
   the following:

      WWW-Authenticate: Basic realm="WallyWorld"

   where "WallyWorld" is the string assigned by the server to identify
   the protection space of the Request-URI. A proxy may respond with the
   same challenge using the Proxy-Authenticate header field.

   To receive authorization, the client sends the userid and password,
   separated by a single colon (":") character, within a base64 [7]
   encoded string in the credentials.

      basic-credentials = base64-user-pass
      base64-user-pass  = <base64 [4] encoding of user-pass,




 
RFC 2617                  HTTP Authentication                  June 1999


                       except not limited to 76 char/line>
      user-pass   = userid ":" password
      userid      = *<TEXT excluding ":">
      password    = *TEXT

   Userids might be case sensitive.

   If the user agent wishes to send the userid "Aladdin" and password
   "open sesame", it would use the following header field:

      Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

   A client SHOULD assume that all paths at or deeper than the depth of
   the last symbolic element in the path field of the Request-URI also