co-Edited by Lem computers d.o.o. © 2000-2005

Fielding, et al. Standards Track [Page 163]

RFC 2616 HTTP/1.1 June 1999

19 Appendices

19.1 Internet Media Type message/http and application/http

In addition to defining the HTTP/1.1 protocol, this document serves

as the specification for the Internet media type "message/http" and

"application/http". The message/http type can be used to enclose a

single HTTP request or response message, provided that it obeys the

MIME restrictions for all "message" types regarding line length and

encodings. The application/http type can be used to enclose a

pipeline of one or more HTTP request or response messages (not

intermixed). The following is to be registered with IANA [17].

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

Media Type name: application

Media subtype name: http

Required parameters: none

Optional parameters: version, msgtype

version: The HTTP-Version number of the enclosed messages

(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: HTTP messages enclosed by this type

are in "binary" format; use of an appropriate

Content-Transfer-Encoding is required when

transmitted via E-mail.

Security considerations: none

Fielding, et al. Standards Track [Page 164]

RFC 2616 HTTP/1.1 June 1999

19.2 Internet Media Type multipart/byteranges

When an HTTP 206 (Partial Content) response message includes the

content of multiple ranges (a response to a request for multiple

non-overlapping ranges), these are transmitted as a multipart

message-body. The 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 required

boundary parameter specifies the boundary string used to separate

each body-part.

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

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

Notes:

1) Additional CRLFs may precede the first boundary string in the

entity.

Fielding, et al. Standards Track [Page 165]

RFC 2616 HTTP/1.1 June 1999

2) Although RFC 2046 [40] permits the boundary string to be

quoted, some existing implementations handle a quoted boundary

string incorrectly.

3) A number of browsers and servers were coded to an early draft

of the byteranges specification to use a media type of

multipart/x-byteranges, which is almost, but not quite

compatible with the version documented in HTTP/1.1.

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 not labeling the entity is preferred over labeling

the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1

and 3.4.1.

Additional rules for requirements on parsing and encoding of dates

and other potential problems with date encodings include:

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

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

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

Fielding, et al. Standards Track [Page 166]

RFC 2616 HTTP/1.1 June 1999

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

19.4 Differences Between HTTP Entities and RFC 2045 Entities

HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC

822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to

allow entities to be transmitted in an open variety of

representations and with extensible mechanisms. However, RFC 2045

discusses mail, and HTTP has a few features that are different from

those described in RFC 2045. 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.

This appendix describes specific areas where HTTP differs from RFC

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

might be required.

19.4.1 MIME-Version

HTTP is not a MIME-compliant protocol. However, HTTP/1.1 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 indicates that the message is in

full compliance with the MIME protocol (as defined in RFC 2045[7]).

Proxies/gateways are responsible for ensuring full compliance (where

possible) when exporting HTTP messages to strict MIME environments.

MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

MIME version "1.0" is the default for use in HTTP/1.1. However,

HTTP/1.1 message parsing and semantics are defined by this document

and not the MIME specification.

19.4.2 Conversion to Canonical Form

RFC 2045 [7] requires that an Internet mail entity be converted to

canonical form prior to being transferred, as described in section 4

of RFC 2049 [48]. Section 3.7.1 of this document describes the forms

allowed for subtypes of the "text" media type when transmitted over

HTTP. RFC 2046 requires that content with a type of "text" represent

line breaks as CRLF and forbids the use of CR or LF outside of line

Fielding, et al. Standards Track [Page 167]

RFC 2616 HTTP/1.1 June 1999

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 MIME

environment SHOULD translate all line breaks within the text media

types described in section 3.7.1 of this document to the RFC 2049

canonical form of CRLF. Note, however, that this might 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.

Implementors should note that conversion will break any cryptographic

checksums applied to the original content unless the original content

is already in canonical form. Therefore, the canonical form is

recommended for any content that uses such checksums in HTTP.

19.4.3 Conversion of Date Formats

HTTP/1.1 uses a restricted set of date formats (section 3.3.1) 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.1 formats and rewrite the date

if necessary.

19.4.4 Introduction of Content-Encoding

RFC 2045 does not include any concept equivalent to HTTP/1.1'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

a function equivalent to Content-Encoding. However, this parameter is

not part of RFC 2045.)

19.4.5 No Content-Transfer-Encoding

HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC

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

Fielding, et al. Standards Track [Page 168]

RFC 2616 HTTP/1.1 June 1999

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.

19.4.6 Introduction of Transfer-Encoding

HTTP/1.1 introduces the Transfer-Encoding header field (section

14.41). Proxies/gateways MUST remove any transfer-coding prior to

forwarding a message via a MIME-compliant protocol.

A process for decoding the "chunked" transfer-coding (section 3.6)

can be represented in pseudo-code as:

length := 0

read chunk-size, chunk-extension (if any) and CRLF

while (chunk-size > 0) {

read chunk-data and CRLF

append chunk-data to entity-body

length := length + chunk-size

read chunk-size and CRLF

}

read entity-header

while (entity-header not empty) {

append entity-header to existing header fields

read entity-header

}

Content-Length := length

Remove "chunked" from Transfer-Encoding

19.4.7 MHTML and Line Length Limitations

HTTP implementations which share code with MHTML [45] implementations

need to be aware of MIME line length limitations. Since HTTP does not

have this limitation, HTTP does not fold long lines. MHTML messages

being transported by HTTP follow all conventions of MHTML, including

line length limitations and folding, canonicalization, etc., since

HTTP transports all message-bodies as payload (see section 3.7.2) and

does not interpret the content or any MIME header lines that might be

contained therein.

19.5 Additional Features

RFC 1945 and RFC 2068 document protocol elements used by some

existing HTTP implementations, but not consistently and correctly

across most HTTP/1.1 applications. Implementors are advised to be

aware of these features, but cannot rely upon their presence in, or

interoperability with, other HTTP/1.1 applications. Some of these

Fielding, et al. Standards Track [Page 169]

RFC 2616 HTTP/1.1 June 1999

describe proposed experimental features, and some describe features

that experimental deployment found lacking that are now addressed in

the base HTTP/1.1 specification.

A number of other headers, such as Content-Disposition and Title,

from SMTP and MIME are also often implemented (see RFC 2076 [37]).

19.5.1 Content-Disposition

The Content-Disposition response-header field has been proposed as a

means for the origin server to suggest a default filename if the user

requests that the content is saved to a file. This usage is derived

from the definition of Content-Disposition in RFC 1806 [35].

content-disposition = "Content-Disposition" ":"

disposition-type *( ";" disposition-parm )

disposition-type = "attachment" | disp-extension-token

disposition-parm = filename-parm | disp-extension-parm

filename-parm = "filename" "=" quoted-string

disp-extension-token = token

disp-extension-parm = token "=" ( token | quoted-string )

An example is

Content-Disposition: attachment; filename="fname.ext"

The receiving user agent SHOULD NOT respect any directory path

information present in the filename-parm parameter, which is the only

parameter believed to apply to HTTP implementations at this time. The

filename SHOULD be treated as a terminal component only.

If this header is used in a response with the application/octet-

stream content-type, the implied suggestion is that the user agent

should not display the response, but directly enter a `save response

as...' dialog.

See section 15.5 for Content-Disposition security issues.

19.6 Compatibility with Previous Versions

It is beyond the scope of a protocol specification to mandate

compliance with previous versions. HTTP/1.1 was deliberately

designed, however, to make supporting previous versions easy. It is

worth noting that, at the time of composing this specification

(1996), we would expect commercial HTTP/1.1 servers to:

- recognize the format of the Request-Line for HTTP/0.9, 1.0, and

1.1 requests;

Fielding, et al. Standards Track [Page 170]

RFC 2616 HTTP/1.1 June 1999

- understand any valid request in the format of HTTP/0.9, 1.0, or

1.1;

- respond appropriately with a message in the same major version

used by the client.

And we would expect HTTP/1.1 clients to:

- recognize the format of the Status-Line for HTTP/1.0 and 1.1

responses;

- understand any valid response in the format of HTTP/0.9, 1.0, or

1.1.

For most implementations of HTTP/1.0, each connection is established

by the client prior to the request and closed by the server after

sending the response. Some implementations implement the Keep-Alive

version of persistent connections described in section 19.7.1 of RFC

2068 [33].

19.6.1 Changes from HTTP/1.0

This section summarizes major differences between versions HTTP/1.0

and HTTP/1.1.

19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP

Addresses

The requirements that clients and servers support the Host request-

header, report an error if the Host request-header (section 14.23) is

missing from an HTTP/1.1 request, and accept absolute URIs (section

5.1.2) are among the most important changes defined by this

specification.

Older HTTP/1.0 clients assumed a one-to-one relationship of IP

addresses and servers; there was no other established mechanism for

distinguishing the intended server of a request than the IP address

to which that request was directed. The changes outlined above will

allow the Internet, once older HTTP clients are no longer common, to

support multiple Web sites from a single IP address, greatly

simplifying large operational Web servers, where allocation of many

IP addresses to a single host has created serious problems. The

Internet will also be able to recover the IP addresses that have been

allocated for the sole purpose of allowing special-purpose domain

names to be used in root-level HTTP URLs. Given the rate of growth of

the Web, and the number of servers already deployed, it is extremely

Fielding, et al. Standards Track [Page 171]

RFC 2616 HTTP/1.1 June 1999

important that all implementations of HTTP (including updates to

existing HTTP/1.0 applications) correctly implement these

requirements:

- Both clients and servers MUST support the Host request-header.

- A client that sends an HTTP/1.1 request MUST send a Host header.

- Servers MUST report a 400 (Bad Request) error if an HTTP/1.1

request does not include a Host request-header.

- Servers MUST accept absolute URIs.

19.6.2 Compatibility with HTTP/1.0 Persistent Connections

Some clients and servers might wish to be compatible with some

previous implementations of persistent connections in HTTP/1.0

clients and servers. Persistent connections in HTTP/1.0 are

explicitly negotiated as they are not the default behavior. HTTP/1.0

experimental implementations of persistent connections are faulty,

and the new facilities in HTTP/1.1 are designed to rectify these

problems. The problem was that some existing 1.0 clients may be

sending Keep-Alive to a proxy server that doesn't understand

Connection, which would then erroneously forward it to the next

inbound server, which would establish the Keep-Alive connection and

result in a hung HTTP/1.0 proxy waiting for the close on the

response. The result is that HTTP/1.0 clients must be prevented from

using Keep-Alive when talking to proxies.

However, talking to proxies is the most important use of persistent

connections, so that prohibition is clearly unacceptable. Therefore,

we need some other mechanism for indicating a persistent connection

is desired, which is safe to use even when talking to an old proxy

that ignores Connection. Persistent connections are the default for

HTTP/1.1 messages; we introduce a new keyword (Connection: close) for

declaring non-persistence. See section 14.10.

The original HTTP/1.0 form of persistent connections (the Connection:

Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]

19.6.3 Changes from RFC 2068

This specification has been carefully audited to correct and

disambiguate key word usage; RFC 2068 had many problems in respect to

the conventions laid out in RFC 2119 [34].

Clarified which error code should be used for inbound server failures

(e.g. DNS failures). (Section 10.5.5).

Fielding, et al. Standards Track [Page 172]

RFC 2616 HTTP/1.1 June 1999

CREATE had a race that required an Etag be sent when a resource is

first created. (Section 10.2.2).

Content-Base was deleted from the specification: it was not

implemented widely, and there is no simple, safe way to introduce it

without a robust extension mechanism. In addition, it is used in a

similar, but not identical fashion in MHTML [45].

Transfer-coding and message lengths all interact in ways that

required fixing exactly when chunked encoding is used (to allow for

transfer encoding that may not be self delimiting); it was important

to straighten out exactly how message lengths are computed. (Sections

3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)

A content-coding of "identity" was introduced, to solve problems

discovered in caching. (section 3.5)

Quality Values of zero should indicate that "I don't want something"

to allow clients to refuse a representation. (Section 3.9)

The use and interpretation of HTTP version numbers has been clarified

by RFC 2145. Require proxies to upgrade requests to highest protocol

version they support to deal with problems discovered in HTTP/1.0

implementations (Section 3.1)

Charset wildcarding is introduced to avoid explosion of character set

names in accept headers. (Section 14.2)

A case was missed in the Cache-Control model of HTTP/1.1; s-maxage

was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,

14.9.3)

The Cache-Control: max-age directive was not properly defined for

responses. (Section 14.9.3)

There are situations where a server (especially a proxy) does not

know the full length of a response but is capable of serving a

byterange request. We therefore need a mechanism to allow byteranges

with a content-range not indicating the full length of the message.

(Section 14.16)

Range request responses would become very verbose if all meta-data

were always returned; by allowing the server to only send needed

headers in a 206 response, this problem can be avoided. (Section

10.2.7, 13.5.3, and 14.27)

Fielding, et al. Standards Track [Page 173]

RFC 2616 HTTP/1.1 June 1999

Fix problem with unsatisfiable range requests; there are two cases:

syntactic problems, and range doesn't exist in the document. The 416

status code was needed to resolve this ambiguity needed to indicate

an error for a byte range request that falls outside of the actual

contents of a document. (Section 10.4.17, 14.16)

Rewrite of message transmission requirements to make it much harder

for implementors to get it wrong, as the consequences of errors here

can have significant impact on the Internet, and to deal with the

following problems:

1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where

this was incorrectly placing a requirement on the behavior of

an implementation of a future version of HTTP/1.x

2. Made it clear that user-agents should retry requests, not

"clients" in general.

3. Converted requirements for clients to ignore unexpected 100

(Continue) responses, and for proxies to forward 100 responses,

into a general requirement for 1xx responses.

4. Modified some TCP-specific language, to make it clearer that

non-TCP transports are possible for HTTP.

5. Require that the origin server MUST NOT wait for the request

body before it sends a required 100 (Continue) response.

6. Allow, rather than require, a server to omit 100 (Continue) if

it has already seen some of the request body.

7. Allow servers to defend against denial-of-service attacks and

broken clients.

This change adds the Expect header and 417 status code. The message

transmission requirements fixes are in sections 8.2, 10.4.18,

8.1.2.2, 13.11, and 14.20.

Proxies should be able to add Content-Length when appropriate.

(Section 13.5.2)

Clean up confusion between 403 and 404 responses. (Section 10.4.4,

10.4.5, and 10.4.11)

Warnings could be cached incorrectly, or not updated appropriately.

(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning

also needed to be a general header, as PUT or other methods may have

need for it in requests.

Fielding, et al. Standards Track [Page 174]

RFC 2616 HTTP/1.1 June 1999

Transfer-coding had significant problems, particularly with

interactions with chunked encoding. The solution is that transfer-

codings become as full fledged as content-codings. This involves

adding an IANA registry for transfer-codings (separate from content

codings), a new header field (TE) and enabling trailer headers in the

future. Transfer encoding is a major performance benefit, so it was

worth fixing [39]. TE also solves another, obscure, downward

interoperability problem that could have occurred due to interactions

between authentication trailers, chunked encoding and HTTP/1.0

clients.(Section 3.6, 3.6.1, and 14.39)

The PATCH, LINK, UNLINK methods were defined but not commonly

implemented in previous versions of this specification. See RFC 2068

[33].

The Alternates, Content-Version, Derived-From, Link, URI, Public and

Content-Base header fields were defined in previous versions of this

specification, but not commonly implemented. See RFC 2068 [33].

20 Index
 

Please see the PostScript version of this RFC for the INDEX.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fielding, et al. Standards Track [Page 175]
 
RFC 2616 HTTP/1.1 June 1999
 
 
21. Full Copyright Statement
 
 Copyright (C) The Internet Society (1999). All Rights Reserved.
 
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works. However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
Acknowledgement
 
 Funding for the RFC Editor function is currently provided by the
 Internet Society.