RFC 2068 HTTP/1.1 January 1997
19 Appendices
19.1 Internet Media Type message/http
In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type "message/http". The
following is to be registered with IANA.
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.1"). 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
19.2 Internet Media Type multipart/byteranges
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart MIME message. The
multipart media type for this purpose is called
"multipart/byteranges".
The multipart/byteranges media type includes two or more parts, each
with its own Content-Type and Content-Range fields. The parts are
separated using a MIME boundary parameter.
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Fielding, et. al. Standards Track [Page 150]
RFC 2068 HTTP/1.1 January 1997
For example:
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 500-999/8000
...the first range...
--THIS_STRING_SEPARATES
Content-type: application/pdf
Content-range: bytes 7000-7999/8000
...the second range
--THIS_STRING_SEPARATES--
19.3 Tolerant Applications
Although this document specifies the requirements for the generation
of HTTP/1.1 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 message-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.
The character set of an entity-body should be labeled as the lowest
common denominator of the character codes used within that body, with
the exception that no label is preferred over the labels US-ASCII or
ISO-8859-1.
Additional rules for requirements on parsing and encoding of dates
and other potential problems with date encodings include:
o HTTP/1.1 clients and caches should assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact
in the past (this helps solve the "year 2000" problem).
Fielding, et. al. Standards Track [Page 151]
RFC 2068 HTTP/1.1 January 1997
o An HTTP/1.1 implementation may internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the
proper value.
o All expiration-related calculations must be done in GMT. The
local time zone MUST NOT influence the calculation or comparison
of an age or expiration time.
o If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it must be converted into GMT using the most
conservative possible conversion.