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
Click on the red underlined text to get to the source
...
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
...
... application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP ...
... HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP,
referred to as HTTP/0.9, was a simple protocol for raw data transfer ...
... version of HTTP,
referred to as HTTP/0.9, was a simple protocol for raw data transfer
across the Internet ...
... modifiers on the request/response semantics. However, HTTP/1.0 does
not sufficiently take into consideration the effects of hierarchical
proxies ...
... connections, or 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
...
...
This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 ...
... HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 in
order to ensure reliable implementation of its features.
...
... 2],
and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
access to resources available from diverse applications.
...
... This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
...
... The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 4 and
transmitted via the connection ...
... An HTTP request message, as defined in section 5. ...
... An HTTP response message, as defined in section 6. ...
... filtering. Except
where either transparent or non-transparent behavior is explicitly
stated, the HTTP proxy requirements apply to both types of
...
... active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request ...
... HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections ...
... the response message for use in answering subsequent requests. The
rules for determining the cacheability of HTTP responses are
defined in section 13. Even if a resource is cacheable, there may
be additional constraints ...
... metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in appendix 19.4.
...
...
Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the
...
... travels the whole chain will pass through four separate connections.
This distinction is important because some HTTP communication options
may apply only to the connection with the nearest, non-tunnel ...
... requirements on cache behavior.
HTTP requirements for cache behavior and cacheable responses are
...
... cache entries, organizations that distribute
subsets of cached data via CD-ROM, and so on. HTTP systems are used
in corporate intranets over high-bandwidth ...
... 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
...
... 19], but other ports can be used. This does
not preclude HTTP from being implemented on top of any other protocol
on the Internet, or on other networks ...
... on the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
...
... 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
...
...
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
...
...
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
...
... the sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components which do not affect
...
...
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
...
... The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
...
... Note that the major and minor numbers MUST be treated as separate
integers and that each MAY be incremented higher than a single digit.
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
...
... Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
...
... version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
MUST NOT be sent.
...
... An application that sends a request or 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
...
... 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 ...
... 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 of
"HTTP/1.1" in their messages, and MUST do so for any message that is
...
... 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
...
... "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
specific HTTP-Version values, see RFC 2145 ...
... not compatible with HTTP/1.0. For more details on when to send
specific HTTP-Version values, see RFC 2145 [36].
...
... The HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant.
...
...
Due to interoperability problems with HTTP/1.0 proxies discovered
since the publication of RFC 2068(-> 2616draft) ...
...
Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions ...
... URN)
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are
simply formatted strings which identify--via name, location, or any
...
...
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI ...
...
The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs ...
...
HTTP applications have historically allowed three different formats
for the representation of date/time stamps:
...
... 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 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 ...
... HTTP/1.0), though they MUST
only generate the RFC 1123std3 format for representing HTTP-date values
in header fields. See section 19.3 for further information.
...
...
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies ...
... Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC ...
... GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include
additional LWS beyond that specifically included as SP in the
...
...
Some HTTP header fields allow a time value to be specified as an
integer number of seconds, represented in decimal, after the time
...
... character set" is more commonly
referred to as a "character encoding." However, since HTTP and
MIME share the same registry ...
...
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter ...
... 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
...
... use here is representative of historical practice, not good
design. For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be
...
...
All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE header field ...
... transport
has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (section 7.2.2), or the desire to
...
... not understand SHOULD return 501 (Unimplemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client.
...
...
The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields ...
... 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 ...
... HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly
infinite buffer ...
...
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.
...
...
Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
...
... Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations SHOULD only use media type parameters when they are
...
... canonical form. An
entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission except for
...
... LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR ...
... LF as being
representative of a line break in text media received via HTTP. In
addition, if the text is represented in a character set that does not
...
... LF respectively, as is the case for
some multi-byte character sets, HTTP allows the use of whatever octet
sequences are defined by that character set to represent the
...
... or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
...
... charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
...
... Unlike in RFC 2046draft, the epilogue of any multipart message MUST be
empty; HTTP applications MUST NOT transmit the epilogue (even if the
original multipart contains an epilogue). These restrictions exist in
order to preserve the self-delimiting nature of a multipart message-
...
... payload. The one exception is the
"multipart/byteranges" type (appendix 19.2) when it appears in a 206
(Partial Content) response, which will be interpreted by some HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP ...
... HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME ...
... The MIME header fields within each body-part of a multipart message-
body do not have any significance to HTTP beyond that defined by
their MIME semantics ...
...
HTTP content negotiation (section 12) uses short "floating point"
numbers to indicate the relative importance ...
... 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
...
... to other human beings. Computer languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content-
...
...
The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766(-> 3282draft | 3066(-> 4647 | 4646)) ...
... 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.
...
... HTTP Message ...
... 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 ...
... least one SP or HT. Applications ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything
beyond the common forms.
...
...
The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body ...
... 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.
...
... HTTP-Version ...
...
OPTIONS * HTTP/1.1
...
...
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 ...
... 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:
...
... receiving and interpreting a request message, a server responds
with an HTTP response message.
...
... HTTP-Version ...
... 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
...
... | "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
...
... HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such
...
...
The entity-body (if any) sent with an HTTP request or response is in
a format and encoding defined by the entity ...
... TCP connection was
established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet ...
... 26] [30]. Implementation experience and
measurements of actual HTTP/1.1 (RFC 2068(-> 2616draft)) implementations show good
results [39 ...
...
Persistent HTTP connections have a number of advantages:
...
... HTTP can evolve more gracefully, since errors can be reported
without the penalty of closing the TCP connection. Clients ...
... Clients using
future versions of HTTP might optimistically try a new feature,
but if communicating with an older server, retry with old
semantics ...
...
HTTP implementations SHOULD implement persistent connections.
...
... HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP ...
... HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client
...
...
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection ...
... Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See section 19.6.2 for more information on backward
compatibility ...
... versions less than 1.1 unless it is explicitly
signaled. See section 19.6.2 for more information on backward
compatibility with HTTP/1.0 clients.
...
... proxy, where N is the number of simultaneously
active users. These guidelines are intended to improve HTTP response
times and avoid congestion.
...
...
Requirements for HTTP/1.1 origin servers:
...
... request-header
field with the "100-continue" expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0
(or earlier) client. There is an exception to this rule: for
...
... 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 ...
... undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version value. ...
... proxy
either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version ...
... next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version of the next-hop
...
... version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status. ...
... Proxies SHOULD maintain a cache recording the HTTP version
numbers received from recently-referenced next-hop servers. ...
... proxy MUST NOT forward a 100 (Continue) response if the
request message was received from an HTTP/1.0 (or earlier)
client and did not include an Expect request-header ...
...
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
...
... Content-Type field. Although this
specification does not define any use for such a body, future
extensions to HTTP might use the OPTIONS body to make more detailed
queries on the server. A server that does not support such an
...
... the capabilities of the server. For example, this can be used to test
a proxy for HTTP/1.1 compliance (or lack thereof).
...
...
body is not defined by this specification, but might be defined by
future extensions to HTTP. Content negotiation MAY be used to select
the appropriate response format ...
... The response to a GET request is cacheable if and only if it meets
the requirements for HTTP caching described in section 13.
...
... return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method ...
... class of status code. Since HTTP/1.0 did not define any 1xx status
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client ...
... status code. Since 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 ...
... The protocol SHOULD be switched only when it is advantageous to do
so. For example, switching to a newer version of HTTP is advantageous
over older versions, and switching to a real-time ...
... receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
...
... 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
...
... client's unacknowledged input buffers
before they can be read and interpreted by the HTTP application.
...
... entity might
include relevant diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication ...
... diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication" [43].
...
...
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
...
... Authorization
header field (section 14.34). HTTP access authentication is explained
in "HTTP Authentication: Basic and Digest Access Authentication ...
... header field (section 14.34). HTTP access authentication is explained
in "HTTP Authentication: Basic and Digest Access Authentication"
[43 ...
... upstream server specified by the URI (e.g.
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS ...
... The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message ...
...
HTTP provides several OPTIONAL challenge-response authentication
mechanisms which can be used by a server to challenge a client
request ...
... access authentication, and the specification of
"basic" and "digest" authentication, are specified in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. This
...
...
Most HTTP responses include an entity which contains information for
interpretation by a human user ...
... user agents are
equally capable of rendering all entity types. For that reason, HTTP
has provisions for several mechanisms for "content negotiation" --
...
... There are two kinds of content negotiation which are possible in
HTTP: server-driven and agent-driven negotiation. These two kinds of
...
...
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.
...
... Caching in HTTP ...
...
HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches ...
... 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 ...
... inextricable from other aspects of the protocol, and because they
interact with each other, it is useful to describe the basic caching
design of HTTP separately from the detailed descriptions of methods,
headers ...
... 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 ...
... cache all Warnings in responses, without
deleting the ones in the first category. Warnings in responses that
are passed to HTTP/1.0 caches carry an extra warning-date field,
which prevents a future HTTP/1.1 ...
... HTTP/1.0 caches carry an extra warning-date field,
which prevents a future HTTP/1.1 recipient from believing an
erroneously cached Warning.
...
... practical or reasonable to display all of them to the user. This
version of HTTP does not specify strict priority rules for deciding
which warnings to display and in what order, but does suggest some
...
...
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
times and validators) are implicit directives to caches. In some
...
... cases, a server or client might need to provide explicit directives
to the HTTP caches. We use the Cache-Control header ...
...
HTTP caching works best when caches can entirely avoid making
requests to the origin server. The primary mechanism for avoiding
...
...
If an origin server wishes to force any HTTP/1.1 cache, no matter how
it is configured, to validate ...
...
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
...
... 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
...
... host performing the calculation." Hosts that use
HTTP, but especially hosts running origin servers and caches, SHOULD
...
...
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
...
... caches along the request path are
compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
the Age header field ...
... 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 ...
... validation
in situations where it is inconvenient to store modification dates,
where the one-second resolution of HTTP date values is not
sufficient, or where the origin server wishes to avoid certain
paradoxes that might arise from the use of modification dates.
...
...
The only function that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison ...
... clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0
servers.
...
...
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 ...
... 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 ...
... 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
...
... 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 should not provide one.
...
... 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.
...
... headers
(except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry.
...
...
Note: some HTTP/1.0 caches are known to violate this expectation
without providing any Warning.
...
...
The purpose of an HTTP cache is to store information received in
response to requests for use in responding to future requests. In
...
... For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories:
...
...
Some features of the HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers ...
... stronger authentication
mechanisms are introduced in later versions of HTTP. Such
authentication mechanisms MAY rely on the values of header fields ...
... URIs 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 ...
...
There is no way for the HTTP protocol to guarantee that all such
cache entries are marked invalid. For example, the request that
...
...
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 ...
... viewing stale resources, this will tend to force service authors
to avoid using HTTP expiration controls and cache controls when
they would otherwise like to. Service ...
... This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields ...
... identity" content-coding is unavailable, then
content-codings commonly understood by HTTP/1.0 clients (i.e.,
"gzip ...
...
Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues will not
work and are not permitted with x-gzip ...
... 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 ...
...
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication ...
...
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication" [43 ...
... response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol might apply these directives to
header fields not defined in HTTP/1.1 ...
... 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 ...
... an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
useful if certain HTTP/1.0 ...
... HTTP/1.0 cache. This might be
useful if certain HTTP/1.0 caches improperly calculate ages or
expiration times, perhaps due to desynchronized clocks.
...
...
Many HTTP/1.0 cache implementations will treat an Expires value that
is less than or equal to the response Date value as being equivalent
...
... 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
...
... header field, it SHOULD consider the response to be
non-cacheable in order to retain compatibility with HTTP/1.0 servers.
...
...
Note: An origin server might wish to use a relatively new HTTP
cache control feature, such as the "private" directive, on 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.
...
... cache-control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
...
... 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 obeying all of the
cache-control directives defined for its native HTTP-version, obeying
certain extensions, and ignoring all directives that it does not
understand.
...
... 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.
...
... used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined prior
to being transferred, unless this is prohibited by the rules in
...
... composite
types MAY contain many body-parts, each with its own MIME and HTTP
headers (including Content-MD5, Content-Transfer-Encoding, and
...
... Note: while the definition of Content-MD5 is exactly the same for
HTTP as in RFC 1864draft for MIME entity ...
... entity-bodies, there are several ways
in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME ...
... MIME entity-bodies. One is that
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
...
... Transfer-Encoding and Content-Encoding. Another is that
HTTP more frequently uses binary content types than MIME, so it is
...
... the digest is the transmission byte order defined for the type.
Lastly, HTTP allows transmission of text types with any of several
line break conventions and not just the canonical form ...
...
When an HTTP message includes the content of a single range (for
example, a response to a request for a single range ...
...
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
...
... semantics as orig-date in
RFC 822std11(-> 2822prop). The field value is an HTTP-date, as described in section
3.3.1; it MUST be sent in RFC 1123std3 [8 ...
... HTTP-date ...
... Date header field MUST be
assigned one by the recipient if the message will be cached by that
recipient or gatewayed via a protocol which requires a Date. An HTTP
implementation without a clock MUST NOT cache responses without
...
... implementation without a clock MUST NOT cache responses without
revalidating them on every use. An HTTP cache, especially a shared
cache ...
...
The HTTP-date sent in a Date header SHOULD NOT represent a date and
time subsequent to the generation of the message. It SHOULD represent
...
...
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
...
...
The format is an absolute date and time as defined by HTTP-date in
section 3.3.1; it MUST be in RFC 1123std3 date format:
...
... HTTP-date ...
... 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.
...
... URI given by the user or referring resource (generally an HTTP URL,
as described in section 3.2.2). The Host ...
... port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for
...
... 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-date ...
... HTTP-date ...
... HTTP-date ...
... HTTP-date ...
...
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
...
... section 14.9) and is defined here for backward compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache ...
... header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant.
...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43 ...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. Unlike
...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43 ...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43] . Unlike
...
...
Since all HTTP entities are represented in HTTP messages as sequences
of bytes, the concept of a byte range ...
...
Since all HTTP entities are represented in HTTP messages as sequences
of bytes, the concept of a byte range is meaningful for any HTTP ...
... HTTP messages as sequences
of bytes, the concept of a byte range is meaningful for any HTTP
entity. (However, not all clients and servers ...
... A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches ought to support byte ranges ...
... 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.
...
... HTTP-date ...
...
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
...
...
Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
...
... 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
...
... 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.
...
... 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 ...
... 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.
...
... header field (section 14.10) whenever Upgrade is present in an
HTTP/1.1 message.
...
...
This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP
...
... 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
...
...
An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable response that is subject ...
...
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 ...
...
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 ...
... 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
...
... HTTP-date ...
... 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.
...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43 ...
...
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. User
agents ...
... 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 are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords ...
... 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
...
... 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.
...
...
Like any generic data transfer protocol, HTTP cannot regulate the
content of the data that is transferred, nor is there any a priori
method ...
... 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.
...
... 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 ...
...
Implementations of HTTP origin servers SHOULD be careful to restrict
the documents returned by HTTP requests to be only those that were
...
... 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 ...
... administrators. If an HTTP server translates
HTTP URIs directly into file system calls, the server MUST take
...
... 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 ...
... 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
...
... 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
...
... 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.
...
...
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks ...
...
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name ...
...
If HTTP clients do not observe this rule, they could be spoofed when
a previously-accessed server's IP address changes. As network ...
... Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition ...
... 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 2183prop ...
...
Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1 ...
... HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a
server to direct clients ...
... 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
...
...
By their very nature, HTTP proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks ...
... target for
malicious exploitation. Because cache contents persist after an HTTP
request is complete, an attack on the cache can reveal information
...
... proxy need to be aware that they are no trustworthier than
the people who run the proxy; HTTP itself cannot solve this problem.
...
... 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
...
... 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
...
...
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:
...
... Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. ...
... Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN ...
... Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/ ...
... S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html. ...
... 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(-> 2617draft), January 1997. ...
... Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068(-> 2616draft), January 1997. ...
... Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639] ...
... 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] ...
... 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 2617draft, June 1999. [jg646] ...
...
In addition to defining the HTTP/1.1 protocol, this document serves
as the specification for the Internet media type ...
... 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 ...
... 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 ...
... version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
...
... version, msgtype
version: The HTTP-Version number of the enclosed messages
(e.g., "1.1"). If not present, the version can be
...
... line of the body.
Encoding considerations: HTTP messages enclosed by this type
are in "binary" format; use of an appropriate
Content-Transfer-Encoding ...
... 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
...
... If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it MUST be converted into GMT ...
... representations and with extensible mechanisms. However, RFC 2045draft
discusses mail, and HTTP has a few features that are different from
those described in RFC 2045draft. These differences were carefully chosen
...
... 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.
...
... Proxies and gateways from MIME environments to HTTP
also need to be aware of the differences because some conversions
might be required.
...
... HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
include a single MIME-Version general-header field ...
... Proxies/gateways are responsible for ensuring full compliance (where
possible) when exporting HTTP messages to strict MIME environments.
...
...
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 ...
... allowed for subtypes of the "text" media type when transmitted over
HTTP. RFC 2046draft requires that content with a type of "text" represent
line breaks ...
... 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 ...
... 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
...
...
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 ...
... media type, proxies and gateways from HTTP to MIME-compliant
protocols MUST either change the value of ...
... Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format
...
...
HTTP implementations which share code with MHTML [45] implementations
need to be aware of MIME ...
... 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
...
... 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
...
... 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
...
... line length limitations and folding, canonicalization, etc., since
HTTP transports all message-bodies as payload (see section 3.7.2) and
...
... 2068(-> 2616draft) document protocol elements used by some
existing HTTP implementations, but not consistently and correctly
across most HTTP/1.1 applications. Implementors ...
... 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.
...
... 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.
...
... 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:
...
... recognize the format of the Request-Line for HTTP/0.9, 1.0, and
1.1 requests; ...
... recognize the format of the Status-Line for HTTP/1.0 and 1.1
responses; ...
... Changes from HTTP/1.0 ...
... 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
...
... 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 ...
... 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
...
... URLs. Given the rate of growth of
the Web, and the number of servers already deployed, it is extremely
important that all implementations of HTTP (including updates to
existing HTTP/1.0 applications) correctly implement these
...
... important that all implementations of HTTP (including updates to
existing HTTP/1.0 applications) correctly implement these
requirements:
...
... Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header ...
... clients and servers might wish to be compatible with some
previous implementations of persistent connections in HTTP/1.0
clients and servers. Persistent connections ...
... clients and servers. Persistent connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0
...
... connections in HTTP/1.0 are
explicitly negotiated as they are not the default behavior. HTTP/1.0
experimental implementations of persistent connections ...
... 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
...
... 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 ...
... 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.
...
... proxies to upgrade requests to highest protocol
version they support to deal with problems discovered in HTTP/1.0
implementations (Section 3.1)
...
...
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 ...
... between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 3.6, 3.6.1, and 14.39)
...