Fielding, et al. Standards Track [Page 140]
RFC 2616 HTTP/1.1 June 1999
If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. See
section 15.1.3 for security considerations.
14.37 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. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. 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.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
14.38 Server
The Server response-header field contains information about the
software used by the origin server to handle the request. The field
can contain multiple product tokens (section 3.8) and comments
identifying the server and any significant subproducts. The product
tokens are listed in order of their significance for identifying the
application.
Server = "Server" ":" 1*( product | comment )
Example:
Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in section 14.45).
Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable
option.
Fielding, et al. Standards Track [Page 141]
RFC 2616 HTTP/1.1 June 1999
14.39 TE
The TE request-header field indicates what extension transfer-codings
it is willing to accept in the response and whether or not it is
willing to accept trailer fields in a chunked transfer-coding. Its
value may consist of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept
parameters (as described in section 3.6).
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer-coding, as
defined in section 3.6.1. This keyword is reserved for use with
transfer-coding values even though it does not itself represent a
transfer-coding.
Examples of its use are:
TE: deflate
TE:
TE: trailers, deflate;q=0.5
The TE header field only applies to the immediate connection.
Therefore, the keyword MUST be supplied within a Connection header
field (section 14.10) whenever TE is present in an HTTP/1.1 message.
A server tests whether a transfer-coding is acceptable, according to
a TE field, using these rules:
1. The "chunked" transfer-coding is always acceptable. If the
keyword "trailers" is listed, the client indicates that it is
willing to accept trailer fields in the chunked response on
behalf of itself and any downstream clients. The implication is
that, if given, the client is stating that either all
downstream clients are willing to accept trailer fields in the
forwarded response, or that it will attempt to buffer the
response on behalf of downstream recipients.
Note: HTTP/1.1 does not define any means to limit the size of a
chunked response such that a client can be assured of buffering
the entire response.
2. If the transfer-coding being tested is one of the transfer-
codings listed in the TE field, then it is acceptable unless it
is accompanied by a qvalue of 0. (As defined in section 3.9, a
qvalue of 0 means "not acceptable.")
Fielding, et al. Standards Track [Page 142]
RFC 2616 HTTP/1.1 June 1999
3. If multiple transfer-codings are acceptable, then the
acceptable transfer-coding with the highest non-zero qvalue is
preferred. The "chunked" transfer-coding always has a qvalue
of 1.
If the TE field-value is empty or if no TE field is present, the only
transfer-coding is "chunked". A message with no transfer-coding is
always acceptable.
14.40 Trailer
The Trailer general field value indicates that the given set of
header fields is present in the trailer of a message encoded with
chunked transfer-coding.
Trailer = "Trailer" ":" 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
so allows the recipient to know which header fields to expect in the
trailer.
If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See section 3.6.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding.
Message header fields listed in the Trailer header field MUST NOT
include the following header fields:
. Transfer-Encoding
. Content-Length
. Trailer
14.41 Transfer-Encoding
The Transfer-Encoding general-header field indicates what (if any)
type of transformation has been applied to the message body in order
to safely transfer it between the sender and the recipient. This
differs from the content-coding in that the transfer-coding is a
property of the message, not of the entity.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-codings are defined in section 3.6. An example is:
Transfer-Encoding: chunked
Fielding, et al. Standards Track [Page 143]
RFC 2616 HTTP/1.1 June 1999
If multiple encodings have been applied to an entity, the transfer-
codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
14.42 Upgrade
The Upgrade general-header allows the client to specify what
additional communication protocols it supports and would like to use
if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
Upgrade = "Upgrade" ":" 1#product
For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. It
does so by allowing the client to advertise its desire to use another
protocol, such as a later version of HTTP with a higher major version
number, even though the current request has been made using HTTP/1.1.
This eases the difficult transition between incompatible protocols by
allowing the client to initiate a request in the more commonly
supported protocol while indicating to the server that it would like
to use a "better" protocol if available (where "better" is determined
by the server, possibly according to the nature of the method and/or
resource being requested).
The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer connection. Upgrade
cannot be used to insist on a protocol change; its acceptance and use
by the server is optional. The capabilities and nature of the
application-layer communication after the protocol change is entirely
dependent upon the new protocol chosen, although the first action
after changing the protocol MUST be a response to the initial HTTP
request containing the Upgrade header field.
The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection
header field (section 14.10) whenever Upgrade is present in an
HTTP/1.1 message.
Fielding, et al. Standards Track [Page 144]
RFC 2616 HTTP/1.1 June 1999
The Upgrade header field cannot be used to indicate a switch to a
protocol on a different connection. For that purpose, it is more
appropriate to use a 301, 302, 303, or 305 redirection response.
This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of section 3.1 and future updates to this
specification. Any token can be used as a protocol name; however, it
will only be useful if both the client and server associate the name
with the same protocol.
14.43 User-Agent
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
14.44 Vary
The Vary field value indicates the set of request-header fields that
fully determines, while the response is fresh, whether a cache is
permitted to use the response to reply to a subsequent request
without revalidation. For uncacheable or stale responses, the Vary
field value advises the user agent about the criteria that were used
to select the representation. A Vary field value of "*" implies that
a cache cannot determine from the request headers of a subsequent
request whether this response is the appropriate representation. See
section 13.6 for use of the Vary header field by caches.
Vary = "Vary" ":" ( "*" | 1#field-name )
An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable response that is subject to server-driven negotiation.
Doing so allows a cache to properly interpret future requests on that
resource and informs the user agent about the presence of negotiation
Fielding, et al. Standards Track [Page 145]
RFC 2616 HTTP/1.1 June 1999
on that resource. A server MAY include a Vary header field with a
non-cacheable response that is subject to server-driven negotiation,
since this might provide the user agent with useful information about
the dimensions over which the response varies at the time of the
response.
A Vary field value consisting of a list of field-names signals that
the representation selected for the response is based on a selection
algorithm which considers ONLY the listed request-header field values
in selecting the most appropriate representation. A cache MAY assume
that the same selection will be made for future requests with the
same values for the listed field names, for the duration of time for
which the response is fresh.
The field-names given are not limited to the set of standard
request-header fields defined by this specification. Field names are
case-insensitive.
A Vary field value of "*" signals that unspecified parameters not
limited to the request-headers (e.g., the network address of the
client), play a role in the selection of the response representation.
The "*" value MUST NOT be generated by a proxy server; it may only be
generated by an origin server.
14.45 Via
The Via general-header field MUST be used by gateways and proxies to
indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of
RFC 822 [9] and is intended to be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of
all senders along the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the
request/response chain. The received-protocol version is appended to
the Via field value when the message is forwarded so that information
about the protocol capabilities of upstream applications remains
visible to all recipients.
Fielding, et al. Standards Track [Page 146]
RFC 2616 HTTP/1.1 June 1999
The protocol-name is optional if and only if it would be "HTTP". The
received-by field is normally the host and optional port number of a
recipient server or client that subsequently forwarded the message.
However, if the real host is considered to be sensitive information,
it MAY be replaced by a pseudonym. If the port is not given, it MAY
be assumed to be the default port of the received-protocol.
Multiple Via field values represents each proxy or gateway that has
forwarded the message. Each recipient MUST append its information
such that the end result is ordered according to the sequence of
forwarding applications.
Comments MAY be used in the Via header field to identify the software
of the recipient proxy or gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional and MAY be removed by any recipient prior to forwarding the
message.
For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at nowhere.com, which completes
the request by forwarding it to the origin server at www.ics.uci.edu.
The request received by www.ics.uci.edu would then have the following
Via header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies and gateways used as a portal through a network firewall
SHOULD NOT, by default, forward the names and ports of hosts within
the firewall region. This information SHOULD only be propagated if
explicitly enabled. If not enabled, the received-by host of any host
behind the firewall SHOULD be replaced by an appropriate pseudonym
for that host.
For organizations that have strong privacy requirements for hiding
internal structures, a proxy MAY combine an ordered subsequence of
Via header field entries with identical received-protocol values into
a single such entry. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Fielding, et al. Standards Track [Page 147]
RFC 2616 HTTP/1.1 June 1999
Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values.
14.46 Warning
The Warning general-header field is used to carry additional
information about the status or transformation of a message which
might not be reflected in the message. This information is typically
used to warn about a possible lack of semantic transparency from
caching operations or transformations applied to the entity body of
the message.
Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
A response MAY carry more than one Warning header.
The warn-text SHOULD be in a natural language and character set that
is most likely to be intelligible to the human user receiving the
response. This decision MAY be based on any available knowledge, such
as the location of the cache or user, the Accept-Language field in a
request, the Content-Language field in a response, etc. The default
language is English and the default character set is ISO-8859-1.
If a character set other than ISO-8859-1 is used, it MUST be encoded
in the warn-text using the method described in RFC 2047 [14].
Warning headers can in general be applied to any message, however
some specific warn-codes are specific to caches and can only be
applied to response messages. New Warning headers SHOULD be added
after any existing Warning headers. A cache MUST NOT delete any
Warning header that it received with a message. However, if a cache
successfully validates a cache entry, it SHOULD remove any Warning
headers previously attached to that entry except as specified for
Fielding, et al. Standards Track [Page 148]
RFC 2616 HTTP/1.1 June 1999
specific Warning codes. It MUST then add any Warning headers received
in the validating response. In other words, Warning headers are those
that would be attached to the most recent relevant response.
When multiple Warning headers are attached to a response, the user
agent ought to inform the user of as many of them as possible, in the
order that they appear in the response. If it is not possible to
inform the user of all of the warnings, the user agent SHOULD follow
these heuristics:
- Warnings that appear early in the response take priority over
those appearing later in the response.
- Warnings in the user's preferred character set take priority
over warnings in other character sets but with identical warn-
codes and warn-agents.
Systems that generate multiple Warning headers SHOULD order them with
this user agent behavior in mind.
Requirements for the behavior of caches with respect to Warnings are
stated in section 13.1.2.
This is a list of the currently-defined warn-codes, each with a
recommended warn-text in English, and a description of its meaning.
110 Response is stale
MUST be included whenever the returned response is stale.
111 Revalidation failed
MUST be included if a cache returns a stale response because an
attempt to revalidate the response failed, due to an inability to
reach the server.
112 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from
the rest of the network for a period of time.
113 Heuristic expiration
MUST be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater
than 24 hours.
199 Miscellaneous warning
The warning text MAY include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST
NOT take any automated action, besides presenting the warning to
the user.
Fielding, et al. Standards Track [Page 149]
RFC 2616 HTTP/1.1 June 1999
214 Transformation applied
MUST be added by an intermediate cache or proxy if it applies any
transformation changing the content-coding (as specified in the
Content-Encoding header) or media-type (as specified in the
Content-Type header) of the response, or the entity-body of the
response, unless this Warning code already appears in the response.
299 Miscellaneous persistent warning
The warning text MAY include arbitrary information to be presented
to a human user, or logged. A system receiving this warning MUST
NOT take any automated action.
If an implementation sends a message with one or more Warning headers
whose version is HTTP/1.0 or lower, then the sender MUST include in
each warning-value a warn-date that matches the date in the response.
If an implementation receives a message with a warning-value that
includes a warn-date, and that warn-date is different from the Date
value in the response, then that warning-value MUST be deleted from
the message before storing, forwarding, or using it. (This prevents
bad consequences of naive caching of Warning header fields.) If all
of the warning-values are deleted for this reason, the Warning header
MUST be deleted as well.
14.47 WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. User
agents are advised to take special care in parsing the WWW-
Authenticate field value as it might contain more than one challenge,
or if more than one WWW-Authenticate header field is provided, the
contents of a challenge itself can contain a comma-separated list of
authentication parameters.
15 Security Considerations
This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 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.
Fielding, et al. Standards Track [Page 150]
RFC 2616 HTTP/1.1 June 1999
15.1 Personal Information
HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption
keys, etc.), and SHOULD be very careful to prevent unintentional
leakage of this information via the HTTP protocol to other sources.
We very strongly recommend that a convenient interface be provided
for the user to control dissemination of such information, and that
designers and implementors be particularly careful in this area.
History shows that errors in this area often create serious security
and/or privacy problems and generate highly adverse publicity for the
implementor's company.
15.1.1 Abuse of Server Log Information
A server is in the position to save personal data about a user's
requests which might identify their reading patterns or subjects of
interest. This information is clearly confidential in nature and its
handling can 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.
15.1.2 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. Four header fields are
worth special mention in this context: Server, Via, Referer and From.
Revealing the specific software version of the server might 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.
Proxies which serve as a portal through a network firewall SHOULD
take special precautions regarding the transfer of header information
that identifies the hosts behind the firewall. In particular, they
SHOULD remove, or replace with sanitized versions, any Via fields
generated behind the firewall.
The Referer header 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
Fielding, et al. Standards Track [Page 151]
RFC 2616 HTTP/1.1 June 1999
the Referer. Even when the personal information has been removed, the
Referer header might 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.
The User-Agent (section 14.43) or Server (section 14.38) header
fields can sometimes be used to determine that a specific client or
server have a particular security hole which might be exploited.
Unfortunately, this same information is often used for other valuable
purposes for which HTTP currently has no better mechanism.
15.1.3 Encoding Sensitive Information in URI's
Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From
information.
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
Authors of services which use the HTTP protocol SHOULD NOT use GET
based forms for the submission of sensitive data, because this will
cause this data to be encoded in the Request-URI. Many existing
servers, proxies, and user agents will log the request URI in some
place where it might be visible to third parties. Servers can use
POST-based form submission instead
15.1.4 Privacy Issues Connected to Accept Headers
Accept request-headers can reveal information about the user to all
servers which are accessed. The Accept-Language header in particular
can reveal information the user would consider to be of a private
nature, because the understanding of particular languages is often
Fielding, et al. Standards Track [Page 152]
RFC 2616 HTTP/1.1 June 1999
strongly correlated to the membership of a particular ethnic group.
User agents which offer the option to configure the contents of an
Accept-Language header to be sent in every request are strongly
encouraged to let the configuration process include a message which
makes the user aware of the loss of privacy involved.
An approach that limits the loss of privacy would be for a user agent
to omit the sending of Accept-Language headers by default, and to ask
the user whether or not to start sending Accept-Language headers to a
server if it detects, by looking for any Vary response-header fields
generated by the server, that such sending could improve the quality
of service.
Elaborate user-customized accept header fields sent in every request,
in particular if these include quality values, can be used by servers
as relatively reliable and long-lived user identifiers. Such user
identifiers would allow content providers to do click-trail tracking,
and would allow collaborating content providers to match cross-server
click-trails or form submissions of individual users. Note that for
many users not behind a proxy, the network address of the host
running the user agent will also serve as a long-lived user
identifier. In environments where proxies are used to enhance
privacy, user agents ought to be conservative in offering accept
header configuration options to end users. As an extreme privacy
measure, proxies could filter the accept headers in relayed requests.
General purpose user agents which provide a high degree of header
configurability SHOULD warn users about the loss of privacy which can
be involved.
15.2 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.
Fielding, et al. Standards Track [Page 153]
RFC 2616 HTTP/1.1 June 1999
15.3 DNS Spoofing
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
mis-association of IP addresses and DNS names. Clients need to be
cautious in assuming the continuing validity of an IP number/DNS name
association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than
caching the result of previous host name lookups. Many platforms
already can cache host name lookups locally when appropriate, and
they SHOULD be configured to do so. It is proper for these lookups to
be cached, however, only when the TTL (Time To Live) information
reported by the name server makes it likely that the cached
information will remain useful.
If HTTP clients cache the results of host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS.
If HTTP clients do not observe this rule, they could be spoofed when
a previously-accessed server's IP address changes. As network
renumbering is expected to become increasingly common [24], the
possibility of this form of attack will grow. Observing this
requirement thus reduces this potential security vulnerability.
This requirement also improves the load-balancing behavior of clients
for replicated servers using the same DNS name and reduces the
likelihood of a user's experiencing failure in accessing sites which
use that strategy.
15.4 Location Headers and Spoofing
If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority.
15.5 Content-Disposition Issues
RFC 1806 [35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC 2183 [49]
(which updates RFC 1806) for details.
Fielding, et al. Standards Track [Page 154]
RFC 2616 HTTP/1.1 June 1999
15.6 Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a
server to direct clients to discard these cached credentials. This is
a significant defect that requires further extensions to HTTP.
Circumstances under which credential caching can interfere with the
application's security model include but are not limited to:
- Clients which have been idle for an extended period following
which the server might wish to cause the client to reprompt the
user for credentials.
- Applications which include a session termination indication
(such as a `logout' or `commit' button on a page) after which
the server side of the application `knows' that there is no
further reason for the client to retain the credentials.
This is currently under separate study. There are a number of work-
arounds to parts of this problem, and we encourage the use of
password protection in screen savers, idle time-outs, and other
methods which mitigate the security problems inherent in this
problem. In particular, user agents which cache credentials are
encouraged to provide a readily accessible mechanism for discarding
cached credentials under user control.
15.7 Proxies and Caching
By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. Compromise of
the systems on which the proxies run can result in serious security
and privacy problems. Proxies have access to security-related
information, personal information about individual users and
organizations, and proprietary information belonging to users and
content providers. A compromised proxy, or a proxy implemented or
configured without regard to security and privacy considerations,
might be used in the commission of a wide range of potential attacks.
Proxy operators should protect the systems on which proxies run as
they would protect any system that contains or transports sensitive
information. In particular, log information gathered at proxies often
contains highly sensitive personal information, and/or information
about organizations. Log information should be carefully guarded, and
appropriate guidelines for use developed and followed. (Section
15.1.1).
Fielding, et al. Standards Track [Page 155]
RFC 2616 HTTP/1.1 June 1999
Caching proxies provide additional potential vulnerabilities, since
the contents of the cache represent an attractive target for
malicious exploitation. Because cache contents persist after an HTTP
request is complete, an attack on the cache can reveal information
long after a user believes that the information has been removed from
the network. Therefore, cache contents should be protected as
sensitive information.
Proxy implementors should consider the privacy and security
implications of their design and coding decisions, and of the
configuration options they provide to proxy operators (especially the
default configuration).
Users of a proxy need to be aware that they are no trustworthier than
the people who run the proxy; HTTP itself cannot solve this problem.
The judicious use of cryptography, when appropriate, may suffice to
protect against a broad range of security and privacy attacks. Such
cryptography is beyond the scope of the HTTP/1.1 specification.
15.7.1 Denial of Service Attacks on Proxies
They exist. They are hard to defend against. Research continues.
Beware.
16 Acknowledgments
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
reuses many of the definitions provided by Nathaniel Borenstein and
Ned Freed for MIME [7]. We hope that their inclusion in this
specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats.
The HTTP protocol has evolved considerably over the 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, John Franks, 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 early aspects of the protocol.
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:
Fielding, et al. Standards Track [Page 156]
RFC 2616 HTTP/1.1 June 1999
Gary Adams Ross Patterson
Harald Tveit Alvestrand Albert Lunde
Keith Ball John C. Mallery
Brian Behlendorf Jean-Philippe Martin-Flatin
Paul Burchard Mitra
Maurizio Codogno David Morris
Mike Cowlishaw Gavin Nicol
Roman Czyborra Bill Perry
Michael A. Dolan Jeffrey Perry
David J. Fiander Scott Powers
Alan Freier Owen Rees
Marc Hedlund Luigi Rizzo
Greg Herlihy David Robinson
Koen Holtman Marc Salomon
Alex Hopmann Rich Salz
Bob Jernigan Allan M. Schiffman
Shel Kaphan Jim Seidman
Rohit Khare Chuck Shotton
John Klensin Eric W. Sink
Martijn Koster Simon E. Spero
Alexei Kosut Richard N. Taylor
David M. Kristol Robert S. Thau
Daniel LaLiberte Bill (BearHeart) Weinman
Ben Laurie Francois Yergeau
Paul J. Leach Mary Ellen Zurko
Daniel DuBois Josh Cohen
Much of the content and presentation of the caching design is due to
suggestions and comments from individuals including: Shel Kaphan,
Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
Most of the specification of ranges is based on work originally done
by Ari Luotonen and John Franks, with additional input from Steve
Zilles.
Thanks to the "cave men" of Palo Alto. You know who you are.
Jim Gettys (the current editor of this document) wishes particularly
to thank Roy Fielding, the previous editor of this document, along
with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
Larry Masinter for their help. And thanks go particularly to Jeff
Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
Fielding, et al. Standards Track [Page 157]
RFC 2616 HTTP/1.1 June 1999
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
Frystyk implemented RFC 2068 early, and we wish to thank them for the
discovery of many of the problems that this document attempts to
rectify.
17 References
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[2] 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, March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
1630, June 1994.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
Locators (URL)", RFC 1738, December 1994.
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, November 1995.
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
Protocol -- HTTP/1.0", RFC 1945, May 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[8] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1123, October 1989.
[9] Crocker, D., "Standard for The Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
Functional Specification," (v1.5), Thinking Machines
Corporation, April 1990.
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
June 1995.
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET
Messages", RFC 1036, December 1987.
Fielding, et al. Standards Track [Page 158]
RFC 2616 HTTP/1.1 June 1999
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
977, February 1986.
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
November 1996.
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590,
November 1996.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[20] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[22] 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.
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
1864, October 1995.
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC
1952, May 1996.
Fielding, et al. Standards Track [Page 159]
RFC 2616 HTTP/1.1 June 1999
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
Dec. 1995. Slightly revised version of paper in Proc. 2nd
International WWW Conference '94: Mosaic and the Web, Oct. 1994,
which is available at
http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
ency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
ISI Research Report ISI/RR-98-463, (original report dated Aug.
1996), USC/Information Sciences Institute, August 1998.
[28] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, March 1992.
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
[30] S. Spero, "Analysis of HTTP Performance Problems,"
http://sunsite.unc.edu/mdma-release/http-prob.html.
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
Digest Access Authentication", RFC 2069, January 1997.
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[35] Troost, R. and Dorner, S., "Communicating Presentation
Information in Internet Messages: The Content-Disposition
Header", RFC 1806, June 1995.
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
[jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February
1997. [jg640]
Fielding, et al. Standards Track [Page 160]
RFC 2616 HTTP/1.1 June 1999
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and
ISO-10646", RFC 2279, January 1998. [jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
Lie, H., and C. Lilley. "Network Performance Effects of
HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
France, September 1997.[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996. [jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998. [jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
August 1998. [jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", RFC
2617, June 1999. [jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
servers," Work in Progress. [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
(HTCPCP/1.0)", RFC 2324, 1 April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header
Field", RFC 2183, August 1997.
Fielding, et al. Standards Track [Page 161]
RFC 2616 HTTP/1.1 June 1999
18 Authors' Addresses
Roy T. Fielding
Information and Computer Science
University of California, Irvine
Irvine, CA 92697-3425, USA
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
James Gettys
World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Jeffrey C. Mogul
Western Research Laboratory
Compaq Computer Corporation
250 University Avenue
Palo Alto, California, 94305, USA
EMail: mogul@wrl.dec.com
Henrik Frystyk Nielsen
World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Larry Masinter
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, CA 94034, USA
EMail: masinter@parc.xerox.com
Fielding, et al. Standards Track [Page 162]
RFC 2616 HTTP/1.1 June 1999
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052, USA
EMail: paulle@microsoft.com
Tim Berners-Lee
Director, World Wide Web Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
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.
2966
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
