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
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>
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.
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.
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 RFC822 [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.
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", RFC1436,
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",
RFC1630, CERN, June 1994.
[3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC1866, MIT/W3C, November 1995.
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, CERN, Xerox PARC,
University of Minnesota, December 1994.
[5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC1521, Bellcore,
Innosoft, September 1993.
[6] Braden, R., "Requirements for Internet hosts - Application and
Support", STD 3, RFC1123, IETF, October 1989.
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, 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", RFC1808,
UC Irvine, June 1995.
[10] Horton, M., and R. Adams, "Standard for interchange of USENET
Messages", RFC1036 (Obsoletes RFC850), 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",
RFC977, UC San Diego, UC Berkeley, February 1986.
[12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC821,
USC/ISI, August 1982.
[13] Postel, J., "Media Type Registration Procedure." RFC1590,
USC/ISI, March 1994.
[14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC959, 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", RFC1737, 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.
[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
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.
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, RFC1521
discusses mail, and HTTP has a few features that are different than
those described in RFC1521. 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 RFC1521 will be
revised. The revisions may include some of the practices found in
HTTP/1.0 but not in RFC1521.
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
RFC1521 requires that an Internet mail entity be converted to
canonical form prior to being transferred, as described in Appendix G
of RFC1521 [5]. Section 3.6.1 of this document describes the forms
allowed for subtypes of the "text" media type when transmitted over
HTTP.
RFC1521 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.
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
RFC1521 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 RFC1521.)
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 RFC1521, 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
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
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.
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.