11.1 Basic Authentication Scheme

   The "basic" authentication scheme is based on the model that the user
   agent 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.






Fielding, et. al.           Standards Track                    [Page 66]

RFC 2068                        HTTP/1.1                    January 1997


   Upon receipt of an unauthorized request for a URI within the
   protection space, the 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.

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

          basic-credentials = "Basic" SP basic-cookie

          basic-cookie   = 

          user-pass   = userid ":" password

          userid      = *

          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==

   See section 15 for security considerations associated with Basic
   authentication.

11.2 Digest Authentication Scheme

   A digest authentication for HTTP is specified in RFC 2069 [32].

12 Content Negotiation

   Most HTTP responses include an entity which contains information for
   interpretation by a human user. Naturally, it is desirable to supply
   the user with the "best available" entity corresponding to the
   request.  Unfortunately for servers and caches, not all users have
   the same preferences for what is "best," and not all user agents are
   equally capable of rendering all entity types. For that reason, HTTP
   has provisions for several mechanisms for "content negotiation" --
   the process of selecting the best representation for a given response



Fielding, et. al.           Standards Track                    [Page 67]

RFC 2068                        HTTP/1.1                    January 1997


   when there are multiple representations available.

     Note: This is not called "format negotiation" because the alternate
     representations may be of the same media type, but use different
     capabilities of that type, be in different languages, etc.

   Any response containing an entity-body MAY be subject to negotiation,
   including error responses.

   There are two kinds of content negotiation which are possible in
   HTTP: server-driven and agent-driven negotiation. These two kinds of
   negotiation are orthogonal and thus may be used separately or in
   combination. One method of combination, referred to as transparent
   negotiation, occurs when a cache uses the agent-driven negotiation
   information provided by the origin server in order to provide
   server-driven negotiation for subsequent requests.