1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
HTTP/1.1
Click on the red underlined text to get to the source
... to determine each other's true capabilities.
This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 ...
... PDAs with low-power radio links and intermittent connectivity. The
goal of HTTP/1.1 is to support the wide diversity of configurations
already deployed while introducing protocol constructs that meet the
...
... transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport ...
... connection for each
request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response ...
... US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
...
... LF
HTTP/1.1 headers can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
...
... DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
...
... Applications sending Request or Response messages, as defined by this
specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
this version number indicates that the sending application is at
...
... 850(-> 1036) [12] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility ...
...
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
...
...
All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer coding values in the Transfer-Encoding header field ...
... appendix 19.4.6.
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding, and MUST ignore transfer coding extensions
they do not understand. A server which receives an entity ...
... clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender ...
... range 0 through 1, where 0 is the minimum and 1 the maximum value.
HTTP/1.1 applications MUST NOT generate more than three digits after
the decimal point. User configuration of these values SHOULD also be
limited in this fashion.
...
... Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag (section
...
... range of) the
response entity be included within the response. HTTP/1.1 uses range
units in the Range ...
...
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges ...
... The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges specified using other units.
...
... implementations may ignore ranges specified using other units.
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
...
...
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic
...
... CRLF's after a POST request. To restate what is explicitly
forbidden by the BNF, an HTTP/1.1 client must not preface or follow
a request with an extra CRLF ...
... For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid ...
... valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length ...
... Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length ...
... allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
...
... example would be
OPTIONS * HTTP/1.1
The absoluteURI form is required when the request is being made to a
...
... Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
...
... versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients ...
... HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies ...
... Request-URI. For example, the request
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
would be forwarded by the proxy ...
... URL character for a reserved purpose. Implementers
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI ...
...
HTTP/1.1 origin servers SHOULD be aware that the exact resource
identified by an Internet request is determined by examining both the
...
... section 19.5.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host ...
... virtual hosts or vanity
hostnames) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:
1. If Request-URI ...
... The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
-- they may be replaced by local equivalents without affecting the
...
...
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection ...
... connection.
o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
(Continue) status followed by a regular response.
...
... (Continue) status followed by a regular response.
o An HTTP/1.1 (or later) server that receives a request from a
HTTP/1.0 (or earlier) client ...
... subject to these requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
...
... HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
respond with 100 (Continue) status and continue to read from the
input stream ...
... Clients SHOULD remember the version number of at least the most
recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
...
... recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
later response from the server, and it sees the connection close
...
... If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
the server, it should assume that the server implements HTTP/1.0 or
...
...
The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... URIs being defined by the origin server.
HTTP/1.1 does not define how a PUT method affects the state of an
...
... does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the request.
...
... multiple user's requests.
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation ...
... not defined by this specification.
HTTP/1.1 origin servers MUST include an appropriate Vary header field
(section 14.43) in any cachable response based on server-driven
...
... automatic selection, though it also does not prevent any such
mechanism from being developed as an extension and used within
HTTP/1.1.
HTTP/1.1 ...
... HTTP/1.1.
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
status codes for enabling agent ...
... negotiation, though it also does not prevent any such mechanism from
being developed as an extension and used within HTTP/1.1. An HTTP/1.1
cache ...
... negotiation, though it also does not prevent any such mechanism from
being developed as an extension and used within HTTP/1.1. An HTTP/1.1
cache performing transparent negotiation ...
... negotiation MUST include a Vary header
field in the response (defining the dimensions of its variance) if it
is cachable to ensure correct interoperation with all HTTP/1.1
clients. The agent ...
... performance can be improved by the use of response caches. The
HTTP/1.1 protocol includes a number of elements intended to make
caching work as well as possible. Because these elements ...
... Caching would be useless if it did not significantly improve
performance. The goal of caching in HTTP/1.1 is to eliminate the need
to send requests in many cases, and to eliminate the need to send
full responses in many other cases. The former reduces the number of
...
... operation require us to be able to relax the goal of semantic
transparency. The HTTP/1.1 protocol allows origin servers, caches,
and clients ...
...
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
times and validators) are implicit directives to caches. In some
...
... section 14.9.4 for a more restrictive way to force revalidation.
If an origin server wishes to force any HTTP/1.1 cache, no matter how
it is configured, to validate ...
... algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
...
... a globally accurate time standard.
Also note that HTTP/1.1 requires origin servers to send a Date header
with every response, giving the time at which the response was
...
... header, in a form appropriate for arithmetic operations.
HTTP/1.1 uses the Age response-header to help convey age information
between caches ...
... 2. age_value, if all of the caches along the response path
implement HTTP/1.1.
Given that we have two independent ways to compute the age of a
...
... and as long as we have either nearly synchronized clocks or all-
HTTP/1.1 paths, one gets a reliable (conservative) result.
Note that this correction is applied at each HTTP/1.1 ...
... HTTP/1.1 paths, one gets a reliable (conservative) result.
Note that this correction is applied at each HTTP/1.1 cache along the
path, so that if there is an HTTP/1.0 ...
... ordering on responses, since it is possible that a later response
intentionally carries an earlier expiration time. However, the
HTTP/1.1 specification requires the transmission of Date headers on
every response, and the Date values are ordered to a granularity of
...
... overhead of an extra round trip if the cached
entry is invalid, the HTTP/1.1 protocol supports the use of
conditional methods.
...
... are defined in section 13.3.3.
In HTTP/1.1, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special
header ...
... entity.
The only function that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison ...
... to evaluate the condition.
These rules allow HTTP/1.1 caches and clients to safely perform sub-
...
... lead to serious problems.
In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag ...
... cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches to respond appropriately.
...
... caches to respond appropriately.
An HTTP/1.1 cache, upon receiving a request, MUST use the most
...
...
A note on rationale: The general principle behind these rules is
that HTTP/1.1 servers and clients should transmit as much non-
redundant information as is available in their responses and
...
... clients should transmit as much non-
redundant information as is available in their responses and
requests. HTTP/1.1 systems receiving this information will make the
most conservative assumptions about the validators they receive.
...
... tags. Generally,
last-modified values received or used by these systems will support
transparent and efficient caching, and so HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
use of a Last-Modified value as a validator by an HTTP/1.0 ...
... use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
should not provide one.
...
...
Some features of the HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers ...
...
The alternative (known as "write-back" or "copy-back" caching) is not
allowed in HTTP/1.1, due to the difficulty of providing consistent
updates and the problems arising from server, cache, or network ...
... This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields ...
... MUST transmit an Age header with a value of 2147483648 (2^31).
HTTP/1.1 caches MUST send an Age header in every response. Caches ...
... HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1.
The cache-control ...
... header is more restrictive. This rule allows an origin
server to provide, for a given response, a longer expiration time to
an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache ...
... wishing to use a Cache-Control directive that restricts, but does
not prevent, caching by an HTTP/1.1-compliant cache may exploit the
requirement ...
... requirement that the max-age directive overrides the Expires
header, and the fact that non-HTTP/1.1-compliant caches do not
observe the max-age directive.
...
... The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an
HTTP/1.1 cache MUST obey the must-revalidate directive; in
particular, if the cache ...
... cache-directives MUST be ignored; it is assumed that any
cache-directive likely to be unrecognized by an HTTP/1.1 cache will
be combined with standard directives (or the response's default
...
... field may not be sent if there are no parameters associated with that
connection option. HTTP/1.1 defines the "close" connection option
for the sender ...
... request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection ...
... entity. It must be possible for the recipient to reliably determine
the end of HTTP/1.1 requests containing an entity-body, e.g., because
the request has a valid ...
... showing the number of bytes actually transferred. For example,
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
...
... directive, that directive overrides the Expires field.
HTTP/1.1 clients and caches MUST treat other invalid date formats,
...
... To mark a response as "never expires," an origin server should use an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers should not send Expires dates more than one
year in the future.
...
... client MUST include a Host header field in all HTTP/1.1 request
messages on the Internet (i.e., on any message corresponding to a
...
... service being requested). If the Host field is not already present,
an HTTP/1.1 proxy MUST add a Host field to the request message ...
... to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
MUST respond with a 400 status code to any HTTP/1.1 ...
... HTTP/1.1 servers
MUST respond with a 400 status code to any HTTP/1.1 request message
which lacks a Host ...
... near the time that the response is generated.
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
...
... header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant.
Pragma directives MUST be passed through by a proxy ...
... recipient SHOULD be ignored by that recipient.
HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1 ...
... HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
caches SHOULD treat "Pragma: no-cache ...
... A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches SHOULD support byte ranges ...
... 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
...
... 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 ...
... header field (section 14.10) whenever Upgrade is present in an
HTTP/1.1 message.
The Upgrade header field ...
... field-name )
An HTTP/1.1 server MUST include an appropriate Vary header field with
any cachable response that is subject ...
... 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
...
... 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
...
...
An HTTP/1.1 server may return multiple challenges with a 401
(Authenticate) response, and each challenge may use a different
...
...
In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type ...
... 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
...
... in the past (this helps solve the "year 2000" problem).
o An HTTP/1.1 implementation may internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the
...
...
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
822) and the Multipurpose Internet Mail Extensions ...
...
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
simplify the process of date comparison. Proxies ...
... 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.
...
...
MIME 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 ...
... MIME, most header fields in multipart body-parts are generally
ignored unless the field name begins with "Content-". In HTTP/1.1,
multipart body-parts may contain any HTTP header fields which are
...
... HTTP is not a MIME-compliant protocol (see appendix 19.4). However,
HTTP/1.1 messages may include a single MIME-Version general-header
field to indicate what version ...
...
MIME version "1.0" is the default for use in HTTP/1.1. However,
HTTP/1.1 message parsing and semantics ...
... 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 ...
... 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
...
... o Host request-headers are required in HTTP/1.1 requests.
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 ...
... HTTP/1.1 requests.
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header ...
... HTTP
implementations, but not consistently and correctly across most
HTTP/1.1 applications. Implementers should be aware of these
features, but cannot rely upon their presence in, or interoperability ...
... features, but cannot rely upon their presence in, or interoperability
with, other HTTP/1.1 applications. Some of these describe proposed
experimental features, and some describe features that experimental ...
... experimental
deployment found lacking that are now addressed in the base HTTP/1.1
specification.
...
... protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. It is
...
... versions easy. It is
worth noting that at the time of composing this specification, we
would expect commercial HTTP/1.1 servers to:
o recognize the format of the Request-Line for HTTP ...
... 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
...
... Connection. Persistent connections are the default for
HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
declaring non-persistence.
...
... proxy
server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1
for parsing the Connection header field ...
... Keep-Alive header itself is optional, and is used only if a
parameter is being sent. HTTP/1.1 does not define any parameters.
If the Keep-Alive ...