As per Relevance of the word interpretation, we have this rfc below:
Network Working Group J. C.
Request for Comments: 2145
Category: Informational R.
UC
J.
H.
MIT/
May 1997
Use and Interpretation
HTTP Version
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Distribution of this document is unlimited. Please send comments
the HTTP working group at .
of the working group are archived
. General
about HTTP and the applications which use HTTP should take place
the mailing list
HTTP request and response messages include an HTTP protocol
number. Some confusion exists concerning the proper use
interpretation of HTTP version numbers, and
interoperability of HTTP implementations of different
versions. This document is an attempt to clarify the situation.
is not a modification of the intended meaning of the
HTTP/1.0 and HTTP/1.1 documents, but it does describe the
of the authors of those documents, and can be considered
when there is any ambiguity in those documents concerning
version numbers, for all versions of HTTP
Mogul, et. al. Informational [Page 1]
RFC 2145 HTTP Version Numbers May 1997
TABLE OF
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Robustness Principle . . . . . . . . . . . . . . . . . . 3
2 HTTP version numbers. . . . . . . . . . . . . . . . . . . . . . 3
2.1 Proxy behavior. . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Compatibility between minor versions of the same
version. . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Which version number to send in a message. . . . . . . . 5
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4 References. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Authors' addresses. . . . . . . . . . . . . . . . . . . . . . . 6
1
HTTP request and response messages include an HTTP protocol
number. According to section 3.1 of the HTTP/1.1 specification [2],
HTTP uses a "." numbering scheme to
versions of the protocol. The protocol versioning policy
intended to allow the sender to indicate the format of a
and its capacity for understanding further HTTP communication
rather than the features obtained via that communication.
change is made to the version number for the addition of
components which do not affect communication behavior or
only add to extensible field values. The number
incremented when the changes made to the protocol add
which do not change the general message parsing algorithm,
which may add to the message semantics and imply
capabilities of the sender. The number is incremented
the format of a message within the protocol is changed
The same language appears in the description of HTTP/1.0 [1].
Many readers of these documents have expressed some confusion
the intended meaning of this policy. Also, some people who
HTTP implementations before RFC1945 [1] was issued were not aware
the intentions behind the introduction of version numbers
HTTP/1.0. This has led to debate and inconsistency regarding the
and interpretation of HTTP version numbers, and has led
interoperability problems in certain cases
Mogul, et. al. Informational [Page 2]
RFC 2145 HTTP Version Numbers May 1997
This document is an attempt to clarify the situation. It is not
modification of the intended meaning of the existing HTTP/1.0
HTTP/1.1 documents, but it does describe the intention of the
of those documents. In any case where either of those two
is ambiguous regarding the use and interpretation of HTTP
numbers, this document should be considered the definitive as to
intentions of the designers of HTTP
The specification described in this document is not part of
specification of any individual version of HTTP, such as HTTP/1.0
HTTP/1.1. Rather, this document describes the use of HTTP
numbers in any version of HTTP (except for HTTP/0.9, which did
include version numbers).
No vendor or other provider of an HTTP implementation should
any compliance with any IETF HTTP specification unless
implementation conditionally complies with the rules in
document
1.1 Robustness
RFC791 [4] defines the "robustness principle" in section 3.2:
an implementation must be conservative in its
behavior, and liberal in its receiving behavior
This principle applies to HTTP, as well. It is the fundamental
for interpreting any part of the HTTP specification that might
be ambiguous. In particular, implementations of HTTP SHOULD
reject messages or generate errors unnecessarily
2 HTTP version
We start by restating the language quoted above from section 3.1
the HTTP/1.1 specification [2]:
It is, and has always been, the explicit intent of
HTTP specification that the interpretation of an HTTP
header does not change between minor versions of the same
version
It is, and has always been, the explicit intent of
HTTP specification that an implementation receiving a
header that it does not understand MUST ignore that header. (
word "ignore" has a special meaning for proxies; see section 2.1
below.)
Mogul, et. al. Informational [Page 3]
RFC 2145 HTTP Version Numbers May 1997
To make this as clear as possible: The major version sent in
message MAY indicate the interpretation of other header fields.
minor version sent in a message MUST NOT indicate the
of other header fields. This reflects the principle that the
version labels the capability of the sender, not the
of the message
Note: In a future version of HTTP, we may introduce a
that explicitly requires a receiving implementation to reject
message if it does not understand certain headers. For example
this might be implemented by means of a header that lists a set
other message headers that must be understood by the recipient
Any implementation claiming at least conditional compliance
this future version of HTTP would have to implement
mechanism. However, no implementation claiming compliance with
lower HTTP version (in particular, HTTP/1.1) will have
implement this mechanism
This future change may be required to support the
Extension Protocol (PEP) [3].
One consequence of these rules is that an HTTP/1.1 message sent to
HTTP/1.0 recipient (or a recipient whose version is unknown) MUST
constructed so that it remains a valid HTTP/1.0 message when
headers not defined in the HTTP/1.0 specification [1] are removed
2.1 Proxy
A proxy MUST forward an unknown header, unless it is protected by
Connection header. A proxy implementing an HTTP version >= 1.1
NOT forward unknown headers that are protected by a
header, as described in section 14.10 of the HTTP/1.1
[2].
We remind the reader that that HTTP version numbers are hop-by-
components of HTTP messages, and are not end-to-end. That is,
HTTP proxy never "forwards" an HTTP version number in either
request or response
2.2 Compatibility between minor versions of the same major
An implementation of HTTP/x.b sending a message to a recipient
version is known to be HTTP/x.a, a < b, MAY send a header that is
defined in the specification for HTTP/x.a. For example, an HTTP/1.1
server may send a "Cache-control" header to an HTTP/1.0 client;
may be useful if the immediate recipient is an HTTP/1.0 proxy,
the ultimate recipient is an HTTP/1.1 client
Mogul, et. al. Informational [Page 4]
RFC 2145 HTTP Version Numbers May 1997
An implementation of HTTP/x.b sending a message to a recipient
version is known to be HTTP/x.a, a < b, MUST NOT depend on
recipient understanding a header not defined in the specification
HTTP/x.a. For example, HTTP/1.0 clients cannot be expected
understand chunked encodings, and so an HTTP/1.1 server must
send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request
2.3 Which version number to send in a
The most strenuous debate over the use of HTTP version numbers
centered on the problem of implementations that do not follow
robustness principle, and which fail to produce useful results
they receive a message with an HTTP minor version higher than
minor version they implement. We consider these
buggy, but we recognize that the robustness principle also
that message senders should make concessions to buggy
when this is truly necessary for interoperation
An HTTP client SHOULD send a request version equal to the
version for which the client is at least conditionally compliant,
whose major version is no higher than the highest version
by the server, if this is known. An HTTP client MUST NOT send
version for which it is not at least conditionally compliant
An HTTP client MAY send a lower request version, if it is known
the server incorrectly implements the HTTP specification, but
after the client has determined that the server is actually buggy
An HTTP server SHOULD send a response version equal to the
version for which the server is at least conditionally compliant,
whose major version is less than or equal to the one received in
request. An HTTP server MUST NOT send a version for which it is
at least conditionally compliant. A server MAY send a 505 (
Version Not Supported) response if cannot send a response using
major version used in the client's request
An HTTP server MAY send a lower response version, if it is known
suspected that the client incorrectly implements the
specification, but this should not be the default, and this
NOT be done if the request version is HTTP/1.1 or greater
Mogul, et. al. Informational [Page 5]
RFC 2145 HTTP Version Numbers May 1997
3 Security
None, except to the extent that security mechanisms introduced in
version of HTTP might depend on the proper interpretation of
version numbers in older implementations
4
1. Berners-Lee, T., R. Fielding, and H. Frystyk.
Transfer Protocol -- HTTP/1.0. RFC 1945, HTTP Working Group, May
1996.
2. Fielding, Roy T., Jim Gettys, Jeffrey C. Mogul, Henrik
Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
3. Khare, Rohit. HTTP/1.2 Extension Protocol (PEP). HTTP
Group, Work in Progress
4. Postel, Jon. Internet Protocol. RFC 791, NIC, September, 1981.
5 Authors'
Jeffrey C.
Western Research
Digital Equipment
250 University
Palo Alto, California, 94305,
Email: mogul@wrl.dec.
Roy T.
Department of Information and Computer
University of
Irvine, CA 92717-3425,
Fax: +1 (714) 824-4056
Email: fielding@ics.uci.
Jim
MIT Laboratory for Computer
545 Technology
Cambridge, MA 02139,
Fax: +1 (617) 258 8682
Email: jg@w3.
Mogul, et. al. Informational [Page 6]
RFC 2145 HTTP Version Numbers May 1997
Henrik Frystyk
W3
MIT Laboratory for Computer
545 Technology
Cambridge, MA 02139,
Fax: +1 (617) 258 8682
Email: frystyk@w3.
Mogul, et. al. Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
