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
RFC 1945 HTTP/1.0 May 1996
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.
RFC 1945 HTTP/1.0 May 1996
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
=31= |