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
version
Click on the red underlined text to get to the source
... systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP,
referred to as HTTP ...
... applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications
to determine each other's true capabilities.
...
... method, URI, and
protocol version, followed by a MIME-like message containing request
modifiers, client ...
... connection with a server. The server responds with a status line,
including the message's protocol version and a success or error code,
followed by a MIME ...
...
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
the sender ...
... 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
communication behavior or which only add to extensible field values.
The <minor> number is incremented when the changes made to the
...
... The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
...
... 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
lower than HTTP ...
...
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 ...
... HTTP-Version of "HTTP/1.1". Use of
this version number indicates that the sending application is at
least conditionally compliant with this specification.
...
... HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant.
...
... Proxy and gateway applications must be careful when forwarding
messages in protocol versions different from that of the application.
Since the protocol version indicates the protocol capability of the
...
... messages in protocol versions different from that of the application.
Since the protocol version indicates the protocol capability of the
sender, a proxy ...
... sender, a proxy/gateway MUST never send a message with a version
indicator which is greater than its actual version; if a higher
...
... gateway MUST never send a message with a version
indicator which is greater than its actual version; if a higher
version request is received, the proxy ...
... indicator which is greater than its actual version; if a higher
version request is received, the proxy/gateway MUST either downgrade
...
... proxy/gateway MUST either downgrade
the request version, respond with an error, or switch to tunnel
...
... proxy/gateway's response to that request MUST be in the same major
version as the request.
Note: Converting between versions ...
... version as the request.
Note: Converting between versions of HTTP may involve modification
of header fields ...
... HTTP may involve modification
of header fields required or forbidden by the versions involved.
...
... Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part
...
... forbidden. Although any token character may appear in a product-
version, this token SHOULD only be used for a version identifier ...
... version identifier
(i.e., successive versions of the same product SHOULD only differ in
the product-version portion of the product value).
...
... (i.e., successive versions of the same product SHOULD only differ in
the product-version portion of the product value).
...
... An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag ...
... General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields ...
... method to be applied to the resource,
the identifier of the resource, and the protocol version in use.
Request = Request-Line ; Section 5.1
...
... token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements ...
...
To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
...
... Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields ...
... The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element ...
... Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields ...
... TCP connection. Clients using
future versions of HTTP might optimistically try a new feature, but
if communicating with an older server, retry with old semantics ...
...
A significant difference between HTTP/1.1 and earlier versions of
HTTP is that persistent connections ...
... connection is
maintained for HTTP 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 SHOULD remember the version number of at least the most
recently used server; if an HTTP/1.1 client ...
... existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI ...
... URIs. For
example, an article may have a URI for identifying "the current
version" which is separate from the URI identifying each particular
version ...
... current
version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI may result in
several other URIs ...
...
The protocol should only be switched when it is advantageous to do
so. For example, switching to a newer version of HTTP is
advantageous over older versions ...
... version of HTTP is
advantageous over older versions, and switching to a real-time,
synchronous ...
... from a local or a third-party copy. The set presented MAY be a subset
or superset of the original version. For example, including local
annotation information about the resource MAY result in a superset of
the metainformation known by the origin server. Use of this response
code ...
... can't complete the request. In this case, the response entity SHOULD
contain a list of the differences between the two versions in a
format defined by the response Content-Type.
...
... The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request
...
... request message. The server is
indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in section
3.1, other than with this error message ...
... error message. The response SHOULD contain
an entity describing why that version is not supported and what other
protocols are supported by that server.
...
... When multiple warnings are attached to a response, it may not be
practical or reasonable to display all of them to the user. This
version of HTTP does not specify strict priority rules for deciding
...
... authentication failures if stronger authentication mechanisms are
introduced in later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields ...
... the named field or fields, and not to the rest of the request or
response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol may apply these directives to
header fields ...
... 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.
...
... multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English
versions, would call for
Content-Language ...
... transaction overhead. It is also used, on updating requests, to
prevent inadvertent modification of the wrong version of a resource.
As a special case, the value "*" matches any current entity of the
...
... SHOULD include a Via field (as described in section 14.44).
Note: Revealing the specific software version of the server may
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes ...
... does so by allowing the client to advertise its desire to use another
protocol, such as a later version of HTTP with a higher major version
number, even though the current request has been made using HTTP/1.1 ...
... protocol, such as a later version of HTTP with a higher major version
number, even though the current request has been made using HTTP/1.1.
This eases the difficult transition between incompatible protocols by
...
... the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of section 3.1 and future updates to this
specification. Any token can be used as a protocol name; however, it
...
... Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
...
... token
The received-protocol indicates the protocol version of the message
received by the server or client ...
... segment of the
request/response chain. The received-protocol version is appended to
the Via field value when the message is forwarded so that information
about the protocol capabilities of upstream ...
... context: Server, Via, Referer and From.
Revealing the specific software version of the server may allow the
server machine to become more vulnerable to attacks against software
...
... firewall. In particular, they
SHOULD remove, or replace with sanitized versions, any Via fields
generated behind the firewall.
...
... Deutsch, P., "GZIP file format specification version 4.3." RFC 1952, Aladdin Enterprises, May 1996. ...
... Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ HTTPLatency.html. ...
... Mills, D., "Network Time Protocol, Version 3, Specification, Implementation and Analysis", RFC 1305draft, University of Delaware, March 1992. ...
... Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, Aladdin Enterprises, May 1996. ...
... Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996. ...
... version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version ...
...
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
...
... version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
...
... MIME-Version ...
... 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 of the MIME ...
... HTTP/1.1 messages may include a single MIME-Version general-header
field to indicate what version of the MIME protocol was used to
construct the message. Use of the MIME-Version ...
... version of the MIME protocol was used to
construct the message. Use of the MIME-Version header field indicates
that the message is in full compliance with the MIME ...
... method is similar to PUT except that the entity contains a
list of differences between the original version of the resource
identified by the Request-URI and the desired content of the resource
...
... "application/diff") and MUST include sufficient information to allow
the server to recreate the changes necessary to convert the original
version of the resource to the desired version.
...
... the server to recreate the changes necessary to convert the original
version of the resource to the desired version.
If the request passes through a cache ...
... method for determining how the patched resource is placed,
and what happens to its predecessor, is defined entirely by the
origin server. If the original version of the resource being patched
included a Content-Version header field ...
... origin server. If the original version of the resource being patched
included a Content-Version header field, the request entity MUST
...
... include a Derived-From header field corresponding to the value of the
original Content-Version header field. Applications are encouraged to
use these fields for constructing versioning relationships and
...
... header field. Applications are encouraged to
use these fields for constructing versioning relationships and
resolving version conflicts.
PATCH requests must obey the message transmission requirements ...
... Content-Version ...
... Version entity-header field defines the version tag
associated with a rendition of an evolving entity ...
... renditions in different representations.
Content-Version = "Content-Version" ":" quoted-string
...
... Content-Version: "2.1.2"
Content-Version: "Fred 19950116-12:26:48"
Content-Version: "2.5a4-omega7"
...
... entity-header field can be used to indicate the
version tag of the resource from which the enclosed entity was
...
... entity being sent was previously retrieved from the same URI and a
Content-Version header was included with the entity when it was last
...
... The URI header field has, in past versions of this specification,
been used as a combination of the existing Location, Content-
Location, and Vary header fields ...
... Compatibility with Previous Versions ...
... It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions ...
... versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. It is
worth noting that at the time of composing this specification, we
would expect commercial HTTP/1.1 ...
... 1.1;
o respond appropriately with a message in the same major version used
by the client.
...
... sending the response. A few implementations implement the Keep-Alive
version of persistent connections described in section 19.7.1.1.
...