[Next] [Previous] [Up] [Top] [Full Contents] [Search]

3. Protocol Parameters

3.1 HTTP Version

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 communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed.

The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.

HTTP-Version	=	"HTTP" "/" 1*DIGIT "." 1*DIGIT
Note that the major and minor numbers should 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 lower than HTTP/12.3. Leading zeroes should be ignored by recipients and never generated by senders.

This document defines both the 0.9 and 1.0 versions of the HTTP protocol. Applications sending Full-Request or Full-Response messages, as defined by this specification, must include an HTTP-Version of "HTTP/1.0".

HTTP servers are required to be able to recognize the format of the Request-Line for all lower-version requests, understand requests with a format within one major number of their native version (i.e. <major1> and <major>), and respond appropriately with a message within the same <major> protocol number (even if the response is simply an error message). HTTP clients are required to be able to recognize the format of the Status-Line for all lower-version responses and understand responses with a format within one major number of their request version. The following hypothetical example illustrates the required behavior.

* Less than 3.0: it should attempt to understand the request and respond (possibly with an error) in its native format;

* Major number of 3: It should understand the request and respond in its native format;

* Major number of 4: It should understand the request and respond with a version 3 message;

* Major number higher than 4: It should attempt to understand the request and respond (possibly with an error) with a version 3 message;

* Less than 2.0: It should attempt to understand the response and unobtrusively warn the user of the version mismatch;

* 2.0--3.4: It should understand the response and be aware that its request may not have been fully understood by the server;

* 3.5 or higher 3: It should understand the response and can assume that the server understood all aspects of the request if the response does not indicate an error;

* 4.0 or higher: It should attempt to understand the response and unobtrusively warn the user of the version mismatch.

Proxies must be careful in forwarding requests that are received in a format different than that of the proxy's native version. Since the protocol version indicates the protocol capability of the sender, a proxy must never send a message with a version indicator which is greater than its native version; if a higher version request is received, the proxy must either downgrade the request version or respond with an error. Requests with a version lower than that of the proxy's native format may be upgraded by the proxy before being forwarded; the proxy's response to that request must follow the normal server requirements.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker