Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1945

Hypertext Transfer Protocol -- HTTP/1.0

Pages: 60
Informational
Errata
Part 3 of 3 – Pages 47 to 60
First   Prev   None

Top   ToC   RFC1945 - Page 47   prevText
11.  Access Authentication

   HTTP provides a simple challenge-response authentication mechanism
   which may be used by a server to challenge a client request and by a
   client to provide authentication information. It uses an extensible,
   case-insensitive token to identify the authentication scheme,
   followed by a comma-separated list of attribute-value pairs which
   carry the parameters necessary for achieving authentication via that
   scheme.

       auth-scheme    = token

       auth-param     = token "=" quoted-string

   The 401 (unauthorized) 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
   challenge applicable to the requested resource.

       challenge      = auth-scheme 1*SP realm *( "," auth-param )

       realm          = "realm" "=" realm-value
       realm-value    = quoted-string

   The realm attribute (case-insensitive) is required for all
   authentication schemes which issue a challenge. The realm value
   (case-sensitive), in combination with the canonical root URL of the
   server being accessed, defines the protection space. These realms
   allow the protected resources on a server to be partitioned into a
   set of protection spaces, each with its own authentication scheme
   and/or authorization database. The realm value is a string, generally
   assigned by the origin server, which may have additional semantics
   specific to the authentication scheme.

   A user agent that wishes to authenticate itself with a server--
   usually, but not necessarily, after receiving a 401 response--may do
   so by including an Authorization header field with the request. The
   Authorization field value consists of credentials containing the
   authentication information of the user agent for the realm of the
   resource being requested.

       credentials    = basic-credentials
                      | ( auth-scheme #auth-param )

   The domain over which credentials can be automatically applied by a
   user agent is determined by the protection space. 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
Top   ToC   RFC1945 - Page 48
   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 server does not wish to accept the credentials sent with a
   request, it should return a 403 (forbidden) response.

   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. That is, they must forward the WWW-Authenticate and
   Authorization headers untouched, and must not cache the response to a
   request containing Authorization. HTTP/1.0 does not provide a means
   for a client to be authenticated with a proxy.

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 authorize 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.

   Upon receipt of an unauthorized request for a URI within the
   protection space, the server should 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 user-ID and password,
   separated by a single colon (":") character, within a base64 [5]
   encoded string in the credentials.

       basic-credentials = "Basic" SP basic-cookie

       basic-cookie      = <base64 [5] encoding of userid-password,
                            except not limited to 76 char/line>
Top   ToC   RFC1945 - Page 49
       userid-password   = [ token ] ":" *TEXT

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

       Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

   The basic authentication scheme is a non-secure method of filtering
   unauthorized access to resources on an HTTP server. It is based on
   the assumption that the connection between the client and the server
   can be regarded as a trusted carrier. As this is not generally true
   on an open network, the basic authentication scheme should be used
   accordingly. In spite of this, clients should implement the scheme in
   order to communicate with servers that use it.

12.  Security Considerations

   This section is meant to inform application developers, information
   providers, and users of the security limitations in HTTP/1.0 as
   described by this document. The discussion does not include
   definitive solutions to the problems revealed, though it does make
   some suggestions for reducing security risks.

12.1  Authentication of Clients

   As mentioned in Section 11.1, the Basic authentication scheme is not
   a secure method of user authentication, nor does it prevent the
   Entity-Body from being transmitted in clear text across the physical
   network used as the carrier. HTTP/1.0 does not prevent additional
   authentication schemes and encryption mechanisms from being employed
   to increase security.

12.2  Safe Methods

   The writers of client software should be aware that the software
   represents the user in their interactions over the Internet, and
   should be careful to allow the user to be aware of any actions they
   may take which may have an unexpected significance to themselves or
   others.

   In particular, the convention has been established that the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, in a
   special way, so that the user is made aware of the fact that a
   possibly unsafe action is being requested.
Top   ToC   RFC1945 - Page 50
   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

12.3  Abuse of Server Log Information

   A server is in the position to save personal data about a user's
   requests which may identify their reading patterns or subjects of
   interest. This information is clearly confidential in nature and its
   handling may be constrained by law in certain countries. People using
   the HTTP protocol to provide data are responsible for ensuring that
   such material is not distributed without the permission of any
   individuals that are identifiable by the published results.

12.4  Transfer of Sensitive Information

   Like any generic data transfer protocol, HTTP cannot regulate the
   content of the data that is transferred, nor is there any a priori
   method of determining the sensitivity of any particular piece of
   information within the context of any given request. Therefore,
   applications should supply as much control over this information as
   possible to the provider of that information. Three header fields are
   worth special mention in this context: Server, Referer and From.

   Revealing the specific software version of the server may allow the
   server machine to become more vulnerable to attacks against software
   that is known to contain security holes. Implementors should make the
   Server header field a configurable option.

   The Referer field allows reading patterns to be studied and reverse
   links drawn. Although it can be very useful, its power can be abused
   if user details are not separated from the information contained in
   the Referer. Even when the personal information has been removed, the
   Referer field may indicate a private document's URI whose publication
   would be inappropriate.

   The information sent in the From field might conflict with the user's
   privacy interests or their site's security policy, and hence it
   should not be transmitted without the user being able to disable,
   enable, and modify the contents of the field. The user must be able
   to set the contents of this field within a user preference or
   application defaults configuration.

   We suggest, though do not require, that a convenient toggle interface
   be provided for the user to enable or disable the sending of From and
   Referer information.
Top   ToC   RFC1945 - Page 51
12.5  Attacks Based On File and Path Names

   Implementations of HTTP origin servers should be careful to restrict
   the documents returned by HTTP requests to be only those that were
   intended by the server administrators. If an HTTP server translates
   HTTP URIs directly into file system calls, the server must take
   special care not to serve files that were not intended to be
   delivered to HTTP clients. For example, Unix, Microsoft Windows, and
   other operating systems use ".." as a path component to indicate a
   directory level above the current one. On such a system, an HTTP
   server must disallow any such construct in the Request-URI if it
   would otherwise allow access to a resource outside those intended to
   be accessible via the HTTP server. Similarly, files intended for
   reference only internally to the server (such as access control
   files, configuration files, and script code) must be protected from
   inappropriate retrieval, since they might contain sensitive
   information. Experience has shown that minor bugs in such HTTP server
   implementations have turned into security risks.

13.  Acknowledgments

   This specification makes heavy use of the augmented BNF and generic
   constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it
   reuses many of the definitions provided by Nathaniel Borenstein and
   Ned Freed for MIME [5]. We hope that their inclusion in this
   specification will help reduce past confusion over the relationship
   between HTTP/1.0 and Internet mail message formats.

   The HTTP protocol has evolved considerably over the past four years.
   It has benefited from a large and active developer community--the
   many people who have participated on the www-talk mailing list--and
   it is that community which has been most responsible for the success
   of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
   Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip
   M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou
   Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve
   special recognition for their efforts in defining aspects of the
   protocol for early versions of this specification.

   Paul Hoffman contributed sections regarding the informational status
   of this document and Appendices C and D.
Top   ToC   RFC1945 - Page 52
   This document has benefited greatly from the comments of all those
   participating in the HTTP-WG. In addition to those already mentioned,
   the following individuals have contributed to this specification:

       Gary Adams                         Harald Tveit Alvestrand
       Keith Ball                         Brian Behlendorf
       Paul Burchard                      Maurizio Codogno
       Mike Cowlishaw                     Roman Czyborra
       Michael A. Dolan                   John Franks
       Jim Gettys                         Marc Hedlund
       Koen Holtman                       Alex Hopmann
       Bob Jernigan                       Shel Kaphan
       Martijn Koster                     Dave Kristol
       Daniel LaLiberte                   Paul Leach
       Albert Lunde                       John C. Mallery
       Larry Masinter                     Mitra
       Jeffrey Mogul                      Gavin Nicol
       Bill Perry                         Jeffrey Perry
       Owen Rees                          Luigi Rizzo
       David Robinson                     Marc Salomon
       Rich Salz                          Jim Seidman
       Chuck Shotton                      Eric W. Sink
       Simon E. Spero                     Robert S. Thau
       Francois Yergeau                   Mary Ellen Zurko
       Jean-Philippe Martin-Flatin

14. References

   [1]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
        Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
        Distributed Document Search and Retrieval Protocol", RFC 1436,
        University of Minnesota, March 1993.

   [2]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
        Unifying Syntax for the Expression of Names and Addresses of
        Objects on the Network as used in the World-Wide Web",
        RFC 1630, CERN, June 1994.

   [3]  Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
        2.0", RFC 1866, MIT/W3C, November 1995.

   [4]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
        Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
        University of Minnesota, December 1994.
Top   ToC   RFC1945 - Page 53
   [5]  Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Mechanisms for Specifying and Describing
        the Format of Internet Message Bodies", RFC 1521, Bellcore,
        Innosoft, September 1993.

   [6]  Braden, R., "Requirements for Internet hosts - Application and
        Support", STD 3, RFC 1123, IETF, October 1989.

   [7]  Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.

   [8]  F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
        J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
        Functional Specification." (v1.5), Thinking Machines
        Corporation, April 1990.

   [9]  Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
        UC Irvine, June 1995.

   [10] Horton, M., and R. Adams, "Standard for interchange of USENET
        Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
        Laboratories, Center for Seismic Studies, December 1987.

   [11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
        A Proposed Standard for the Stream-Based Transmission of News",
        RFC 977, UC San Diego, UC Berkeley, February 1986.

   [12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
        USC/ISI, August 1982.

   [13] Postel, J., "Media Type Registration Procedure." RFC 1590,
        USC/ISI, March 1994.

   [14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
        STD 9, RFC 959, USC/ISI, October 1985.

   [15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
        1700, USC/ISI, October 1994.

   [16] Sollins, K., and L. Masinter, "Functional Requirements for
        Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
        December 1994.

   [17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
        for Information Interchange. Standard ANSI X3.4-1986, ANSI,
        1986.
Top   ToC   RFC1945 - Page 54
   [18] ISO-8859. International Standard -- Information Processing --
        8-bit Single-Byte Coded Graphic Character Sets --
        Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
        Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
        Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
        Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
        Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
        Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
        Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
        Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
        Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

15.  Authors' Addresses

   Tim Berners-Lee
   Director, W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, U.S.A.

   Fax: +1 (617) 258 8682
   EMail: timbl@w3.org


   Roy T. Fielding
   Department of Information and Computer Science
   University of California
   Irvine, CA 92717-3425, U.S.A.

   Fax: +1 (714) 824-4056
   EMail: fielding@ics.uci.edu


   Henrik Frystyk Nielsen
   W3 Consortium
   MIT Laboratory for Computer Science
   545 Technology Square
   Cambridge, MA 02139, U.S.A.

   Fax: +1 (617) 258 8682
   EMail: frystyk@w3.org
Top   ToC   RFC1945 - Page 55
Appendices

   These appendices are provided for informational reasons only -- they
   do not form a part of the HTTP/1.0 specification.

A.  Internet Media Type message/http

   In addition to defining the HTTP/1.0 protocol, this document serves
   as the specification for the Internet media type "message/http". The
   following is to be registered with IANA [13].

       Media Type name:         message

       Media subtype name:      http

       Required parameters:     none

       Optional parameters:     version, msgtype

              version: The HTTP-Version number of the enclosed message
                       (e.g., "1.0"). If not present, the version can be
                       determined from the first line of the body.

              msgtype: The message type -- "request" or "response". If
                       not present, the type can be determined from the
                       first line of the body.

       Encoding considerations: only "7bit", "8bit", or "binary" are
                                permitted

       Security considerations: none

B.  Tolerant Applications

   Although this document specifies the requirements for the generation
   of HTTP/1.0 messages, not all applications will be correct in their
   implementation. We therefore recommend that operational applications
   be tolerant of deviations whenever those deviations can be
   interpreted unambiguously.

   Clients should be tolerant in parsing the Status-Line and servers
   tolerant when parsing the Request-Line. In particular, they should
   accept any amount of SP or HT characters between fields, even though
   only a single SP is required.

   The line terminator for HTTP-header fields is the sequence CRLF.
   However, we recommend that applications, when parsing such headers,
   recognize a single LF as a line terminator and ignore the leading CR.
Top   ToC   RFC1945 - Page 56
C.  Relationship to MIME

   HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC
   822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to
   allow entities to be transmitted in an open variety of
   representations and with extensible mechanisms. However, RFC 1521
   discusses mail, and HTTP has a few features that are different than
   those described in RFC 1521. These differences were carefully chosen
   to optimize performance over binary connections, to allow greater
   freedom in the use of new media types, to make date comparisons
   easier, and to acknowledge the practice of some early HTTP servers
   and clients.

   At the time of this writing, it is expected that RFC 1521 will be
   revised. The revisions may include some of the practices found in
   HTTP/1.0 but not in RFC 1521.

   This appendix describes specific areas where HTTP differs from RFC
   1521. Proxies and gateways to strict MIME environments should be
   aware of these differences and provide the appropriate conversions
   where necessary. Proxies and gateways from MIME environments to HTTP
   also need to be aware of the differences because some conversions may
   be required.

C.1  Conversion to Canonical Form

   RFC 1521 requires that an Internet mail entity be converted to
   canonical form prior to being transferred, as described in Appendix G
   of RFC 1521 [5]. Section 3.6.1 of this document describes the forms
   allowed for subtypes of the "text" media type when transmitted over
   HTTP.

   RFC 1521 requires that content with a Content-Type of "text"
   represent line breaks as CRLF and forbids the use of CR or LF outside
   of line break sequences. HTTP allows CRLF, bare CR, and bare LF to
   indicate a line break within text content when a message is
   transmitted over HTTP.

   Where it is possible, a proxy or gateway from HTTP to a strict RFC
   1521 environment should translate all line breaks within the text
   media types described in Section 3.6.1 of this document to the RFC
   1521 canonical form of CRLF. Note, however, that this may be
   complicated by the presence of a Content-Encoding and by the fact
   that HTTP allows the use of some character sets which do not use
   octets 13 and 10 to represent CR and LF, as is the case for some
   multi-byte character sets.
Top   ToC   RFC1945 - Page 57
C.2  Conversion of Date Formats

   HTTP/1.0 uses a restricted set of date formats (Section 3.3) to
   simplify the process of date comparison. Proxies and gateways from
   other protocols should ensure that any Date header field present in a
   message conforms to one of the HTTP/1.0 formats and rewrite the date
   if necessary.

C.3  Introduction of Content-Encoding

   RFC 1521 does not include any concept equivalent to HTTP/1.0's
   Content-Encoding header field. Since this acts as a modifier on the
   media type, proxies and gateways from HTTP to MIME-compliant
   protocols must either change the value of the Content-Type header
   field or decode the Entity-Body before forwarding the message. (Some
   experimental applications of Content-Type for Internet mail have used
   a media-type parameter of ";conversions=<content-coding>" to perform
   an equivalent function as Content-Encoding. However, this parameter
   is not part of RFC 1521.)

C.4  No Content-Transfer-Encoding

   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
   1521. Proxies and gateways from MIME-compliant protocols to HTTP must
   remove any non-identity CTE ("quoted-printable" or "base64") encoding
   prior to delivering the response message to an HTTP client.

   Proxies and gateways from HTTP to MIME-compliant protocols are
   responsible for ensuring that the message is in the correct format
   and encoding for safe transport on that protocol, where "safe
   transport" is defined by the limitations of the protocol being used.
   Such a proxy or gateway should label the data with an appropriate
   Content-Transfer-Encoding if doing so will improve the likelihood of
   safe transport over the destination protocol.

C.5  HTTP Header Fields in Multipart Body-Parts

   In RFC 1521, most header fields in multipart body-parts are generally
   ignored unless the field name begins with "Content-". In HTTP/1.0,
   multipart body-parts may contain any HTTP header fields which are
   significant to the meaning of that part.

D.  Additional Features

   This appendix documents protocol elements used by some existing HTTP
   implementations, but not consistently and correctly across most
   HTTP/1.0 applications. Implementors should be aware of these
   features, but cannot rely upon their presence in, or interoperability
Top   ToC   RFC1945 - Page 58
   with, other HTTP/1.0 applications.

D.1  Additional Request Methods

D.1.1 PUT

   The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity should be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI.

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity as data to be processed. That resource may be a data-accepting
   process, a gateway to some other protocol, or a separate entity that
   accepts annotations. In contrast, the URI in a PUT request identifies
   the entity enclosed with the request -- the user agent knows what URI
   is intended and the server should not apply the request to some other
   resource.

D.1.2 DELETE

   The DELETE method requests that the origin server delete the resource
   identified by the Request-URI.

D.1.3 LINK

   The LINK method establishes one or more Link relationships between
   the existing resource identified by the Request-URI and other
   existing resources.

D.1.4 UNLINK

   The UNLINK method removes one or more Link relationships from the
   existing resource identified by the Request-URI.

D.2  Additional Header Field Definitions

D.2.1 Accept

   The Accept request-header field can be used to indicate a list of
   media ranges which are acceptable as a response to the request. The
   asterisk "*" character is used to group media types into ranges, with
   "*/*" indicating all media types and "type/*" indicating all subtypes
Top   ToC   RFC1945 - Page 59
   of that type. The set of ranges given by the client should represent
   what types are acceptable given the context of the request.

D.2.2 Accept-Charset

   The Accept-Charset request-header field can be used to indicate a
   list of preferred character sets other than the default US-ASCII and
   ISO-8859-1. This field allows clients capable of understanding more
   comprehensive or special-purpose character sets to signal that
   capability to a server which is capable of representing documents in
   those character sets.

D.2.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-coding values which are acceptable in the
   response.

D.2.4 Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.

D.2.5 Content-Language

   The Content-Language entity-header field describes the natural
   language(s) of the intended audience for the enclosed entity. Note
   that this may not be equivalent to all the languages used within the
   entity.

D.2.6 Link

   The Link entity-header field provides a means for describing a
   relationship between the entity and some other resource. An entity
   may include multiple Link values. Links at the metainformation level
   typically indicate relationships like hierarchical structure and
   navigation paths.

D.2.7 MIME-Version

   HTTP messages may include a single MIME-Version general-header field
   to indicate what version of the MIME protocol was used to construct
   the message. Use of the MIME-Version header field, as defined by RFC
   1521 [5], should indicate that the message is MIME-conformant.
   Unfortunately, some older HTTP/1.0 servers send it indiscriminately,
   and thus this field should be ignored.
Top   ToC   RFC1945 - Page 60
D.2.8 Retry-After

   The Retry-After response-header field can be used with a 503 (service
   unavailable) response to indicate how long the service is expected to
   be unavailable to the requesting client. The value of this field can
   be either an HTTP-date or an integer number of seconds (in decimal)
   after the time of the response.

D.2.9 Title

   The Title entity-header field indicates the title of the entity.

D.2.10 URI

   The URI entity-header field may contain some or all of the Uniform
   Resource Identifiers (Section 3.2) by which the Request-URI resource
   can be identified. There is no guarantee that the resource can be
   accessed using the URI(s) specified.