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
...
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 ...
...
HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
...
...
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
...
... response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least conditionally
compliant with this specification SHOULD use an HTTP-Version ...
... compliant with this specification SHOULD use an HTTP-Version of
"HTTP/1.1" in their messages, and MUST do so for any message that is
not compatible with HTTP/1.0. For more details on when to send
...
... 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 ...
... clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender ...
...
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 TE header field ...
... requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 ...
...
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand.
...
... value. If a parameter has a quality value of 0, then content with
this parameter is `not acceptable' for the client. HTTP/1.1
applications MUST NOT generate more than three digits after the
decimal point. User configuration of these values SHOULD also be
...
... 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.
...
...
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
...
... 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 ...
...
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.
...
...
OPTIONS * HTTP/1.1
...
...
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
...
... 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 ...
... URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI ...
... Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see
section 19.6.1.1 for other requirements on Host ...
... virtual hosts or vanity host
names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:
...
... 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
recommendations -- they MAY be replaced by local equivalents without
...
... 26] [30]. Implementation experience and
measurements of actual HTTP/1.1 (RFC 2068(-> 2616draft)) implementations show good
results [39 ...
...
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection ...
...
Requirements for HTTP/1.1 origin servers:
...
... compatibility with RFC 2068(-> 2616draft), a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
...
... client processing delays associated with an
undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version ...
... proxy
either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version ...
...
If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header ...
... "100-continue" expectation, and if the client is not directly
connected to an HTTP/1.1 origin server, and if the client sees the
connection ...
...
The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... the capabilities of the server. For example, this can be used to test
a proxy for HTTP/1.1 compliance (or lack thereof).
...
... response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the
...
...
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
...
...
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation ...
... 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 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 that could be used within HTTP/1.1.
...
... 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 ...
... HTTP/1.0 caches carry an extra warning-date field,
which prevents a future HTTP/1.1 recipient from believing an
erroneously cached Warning.
...
...
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
times and validators) are implicit directives to caches. In some
...
...
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
...
...
HTTP/1.1 requires origin servers to send a Date header, if possible,
with every response, giving the time at which the response was
...
...
and as long as we have either nearly synchronized clocks or all-
HTTP/1.1 paths, one gets a reliable (conservative) result.
...
... response is first-hand unless all caches along the request path are
compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
...
... overhead of an extra round trip if the cached
entry is invalid, the HTTP/1.1 protocol supports the use of
conditional methods.
...
...
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 ...
...
The only function that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison ...
...
HTTP/1.1 origin servers:
...
...
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. ...
...
An HTTP/1.1 origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since or
...
...
Note: The general principle behind these rules is that HTTP/1.1
servers and clients should transmit as much non-redundant
...
... 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
...
... where the 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 ...
... overflows, it MUST transmit an Age header with a value of
2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
include an Age header field ...
... 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 ...
... to the Cache-Control response directive "no-cache". If an HTTP/1.1
cache receives such a response, and the response does not include a
...
... 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 pre-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
...
...
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection ...
... token. This protects against mistaken
forwarding of such header fields by pre-HTTP/1.1 proxies. See section
19.6.2.
...
...
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
return a 417 (Expectation Failed) status if it receives a request
...
... To mark a response as "never expires," an origin server sends 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 . If the requested URI does not include an Internet ...
... Host header field MUST
be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
request message ...
... proxy. All
Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 ...
... HTTP/1.1 servers MUST respond with a 400 (Bad Request)
status code to any HTTP/1.1 request message which lacks a Host header
field ...
...
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.
...
... A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches ought to support byte ranges ...
...
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 ...
...
An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
...
... 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.
...
...
An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable 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
...
... HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a
server to direct clients ...
... Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068(-> 2616draft), January 1997. ...
... 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] ...
...
In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type ...
... multipart/x-byteranges, which is almost, but not quite
compatible with the version documented in HTTP/1.1.
...
... 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
...
... 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 is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
include a single MIME-Version general-header field ...
...
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 ...
...
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.
...
...
RFC 2045draft does not include any concept equivalent to HTTP/1.1's
Content-Encoding header field ...
... 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
...
... aware of these 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
...
... 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
(1996), we would expect commercial HTTP/1.1 servers to:
...
... 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
...
... Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header ...
... 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. See section 14.10.
...
...
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)
...
... Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
this was incorrectly placing a requirement ...