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.0
Click on the red underlined text to get to the source
... modifiers on the request/response semantics. However, HTTP/1.0 does
not sufficiently take into consideration the effects of hierarchical
proxies ...
... connections, and virtual
hosts. In addition, the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications
...
... HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 in
order to ensure reliable implementation of its features.
...
... of this specification.
In HTTP/1.0, most implementations used a new connection for each
request/response ...
... clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123std3 format for representing HTTP ...
... (Unimplemented), and close the connection. A server MUST NOT send
transfer-codings to an HTTP/1.0 client.
...
... it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter ...
... versions less than 1.1 unless it is explicitly
signaled. See section 19.7.1 for more information on backwards
compatibility with HTTP/1.0 clients.
...
... o An HTTP/1.1 (or later) server that receives a request from a
HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
response; it SHOULD either wait for the request to be completed
...
... 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
older and will not use the 100 (Continue) response. If in this case
the client ...
... client SHOULD retry the request. If the client does
retry the request to this HTTP/1.0 server, it should use the
following "binary exponential backoff" algorithm to be assured of
...
... consisting only of the Status-Line and optional headers, and is
terminated by an empty line. Since HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 ...
... HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental ...
... receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
...
... receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
...
... Warnings are always cachable, because they never weaken the
transparency of a response. This means that warnings can be passed to
HTTP/1.0 caches without danger; such caches will simply pass the
...
... HTTP/1.1 cache along the
path, so that if there is an HTTP/1.0 cache in the path, the correct
received age is computed as long as the receiving ...
... clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0
servers.
...
... cache-conditional
requests (using If-Modified-Since).
o If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that value in subrange cache-conditional
...
... provided by the origin server, SHOULD use both validators in
cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches ...
... most conservative assumptions about the validators they receive.
HTTP/1.0 clients and caches will ignore entity ...
... 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 system
could result in a serious problem, then HTTP/1.1 origin servers
...
... headers
(except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry.
...
... header to the current time.
Note that some HTTP/1.0 caches are known to violate this
expectation without providing any Warning.
...
... URLs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs should not
be taken from a cache ...
... should be given in the response.
Note that HTTP/1.0 caches may not implement Cache-Control and may
...
... an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 ...
... HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 caches improperly calculate ages or
expiration times, perhaps due to desynchronized clocks.
...
... Cache-Control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
...
... section 14.9) and is defined here for backwards compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache ...
... Transfer-Encoding: chunked
Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
...
...
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 ...
... Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC ...
... Changes from HTTP/1.0 ...
... important that all implementations of HTTP (including updates to
existing HTTP/1.0 applications) correctly implement these
requirements:
...
... clients and servers may wish to be compatible with some previous
implementations of persistent connections in HTTP/1.0 clients and
servers. Persistent connections in HTTP/1.0 ...
... HTTP/1.0 clients and
servers. Persistent connections in HTTP/1.0 must be explicitly
negotiated as they are not the default behavior. HTTP/1.0
...
... connections in HTTP/1.0 must be explicitly
negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections ...
... 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 ...
... 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 ...
... declaring non-persistence.
The following describes the original HTTP/1.0 form of persistent
connections.
...
... HTTP/1.1 server may also establish persistent connections with
HTTP/1.0 clients upon receipt of a Keep-Alive connection ...
... token.
However, a persistent connection with an HTTP/1.0 client cannot make
use of the chunked transfer-coding, and therefore MUST use a
...
... connection token to a proxy
server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1
...