RFC 2145

Use and Interpretation of HTTP Version Numbers

📅 published May 1997, from ietf

RFC 2145: Use and Interpretation of HTTP Version Numbers 🎀

okay so bestie, this is RFC 2145 ✨ It's titled "Use and Interpretation of HTTP Version Numbers," and it was published in May 1997 as an Informational doc from the Network Working Group. The authors are J. C. Mogul (DEC), R. Fielding (UC Irvine), J. Gettys (DEC), and H. Frystyk (MIT/LCS). The title block doesn't say it obsoletes or updates anything. 💅

Status of this Memo 🌸

so this memo is just here to inform the internet community. It does NOT set any kind of internet standard, and you can share it around as much as you want because distribution is unlimited 🫶

Distribution of this doc is unlimited too (yes, it's said twice, the authors were clearly feeling it). If you want to send comments, the HTTP working group's address is <http-wg@cuckoo.hpl.hp.com>. The working group's discussions are archived at <URL:http://www.ics.uci.edu/pub/ietf/http/>. General chat about HTTP and the apps that use it should happen on the <www-talk@w3.org> mailing list 💬

Abstract 🦋

okay the big idea: HTTP request and response messages both carry an HTTP protocol version number. People have been kind of confused about how to use those numbers properly, and about whether HTTP implementations on different protocol versions can actually talk to each other. This doc is the clarification. It doesn't change what HTTP/1.0 and HTTP/1.1 meant. It describes what the authors of those docs intended, and it counts as the final word on version numbers whenever those two docs are ambiguous, for all versions of HTTP 🔥

Table of Contents 💜

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 major
         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. Introduction ✨

okay so HTTP requests and responses carry a protocol version number. The HTTP/1.1 spec says this, in section 3.1 of [2]:

      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.

HTTP/1.0 [1] uses the exact same language 🌈

Lowkey, a bunch of people have been confused about what this policy actually means. Some folks who built HTTP implementations before RFC1945 [1] came out also had no clue what the authors were going for when they added version numbers in HTTP/1.0. That led to arguments, inconsistent behavior, and in some cases real interoperability problems 😭

So this doc steps in. It isn't a change to what HTTP/1.0 and HTTP/1.1 meant. It describes what their authors intended. If either of those docs is ambiguous about HTTP version numbers, this doc should be treated as the definitive word on what the HTTP designers intended 👑

The rules here aren't part of any single HTTP version's spec, like HTTP/1.0 or HTTP/1.1. Instead, they cover how version numbers get used in any version of HTTP, with one exception: HTTP/0.9, which didn't have version numbers at all 🧚

And here's the important bit: no vendor or other provider of an HTTP implementation should claim compliance with any IETF HTTP spec unless their implementation conditionally complies with the rules in this document. No shortcuts, bestie 💅

1.1. Robustness Principle 🎀

RFC791 [4] defines the "robustness principle" in section 3.2:

       an implementation must be conservative in its sending
    behavior, and liberal in its receiving behavior.

This principle applies to HTTP too! It's the core foundation for reading any part of the HTTP spec that might still be ambiguous. Specifically, implementations of HTTP SHOULD NOT reject messages or generate errors unnecessarily. Be chill with the errors, you know? 🙈

2. HTTP version numbers 💖

okay let's restate the language we already quoted from section 3.1 of the HTTP/1.1 spec [2]:

       It is, and has always been, the explicit intent of the
   HTTP specification that the interpretation of an HTTP message
   header does not change between minor versions of the same major
   version.

       It is, and has always been, the explicit intent of the
   HTTP specification that an implementation receiving a message
   header that it does not understand MUST ignore that header.  (The
   word "ignore" has a special meaning for proxies; see section 2.1
   below.)

Here's the spiciest part, so pay attention 👀 The major version sent in a message MAY indicate how the other header fields should be interpreted. But the minor version sent in a message MUST NOT indicate how the other header fields should be interpreted. The reason is that the minor version tells you what the sender is capable of, not how to read the message 🦋

Note: In a future version of HTTP, we might introduce a mechanism that explicitly requires a receiving implementation to reject a message if it does not understand certain headers. For example, this could be done with a header that lists a set of other message headers the recipient has to understand. Any implementation claiming at least conditional compliance with that future version of HTTP would have to implement this mechanism. However, no implementation claiming compliance with a lower HTTP version (in particular, HTTP/1.1) will have to implement this mechanism. This future change may be required to support the Protocol Extension Protocol (PEP) [3].

One consequence of all this is that an HTTP/1.1 message sent to an HTTP/1.0 recipient (or to a recipient whose version is unknown) MUST be constructed so that it's still a valid HTTP/1.0 message after you strip out every header that isn't defined in the HTTP/1.0 spec [1]. Main character energy: build it so the old recipient can still read it 🎀

2.1. Proxy behavior 🦋

A proxy MUST forward an unknown header, unless that header is protected by a Connection header. A proxy implementing an HTTP version >= 1.1 MUST NOT forward unknown headers that are protected by a Connection header, as described in section 14.10 of the HTTP/1.1 spec [2].

Just a reminder, HTTP version numbers are hop-by-hop parts of HTTP messages, not end-to-end ones. So an HTTP proxy never "forwards" an HTTP version number in either a request or a response 🧚

2.2. Compatibility between minor versions of the same major version 🌸

An implementation of HTTP/x.b sending a message to a recipient whose version is known to be HTTP/x.a, where a < b, MAY send a header that isn't defined in the spec for HTTP/x.a. For example, an HTTP/1.1 server may send a "Cache-control" header to an HTTP/1.0 client. That can be useful when the immediate recipient is an HTTP/1.0 proxy but the ultimate recipient is an HTTP/1.1 client 💅

An implementation of HTTP/x.b sending a message to a recipient whose version is known to be HTTP/x.a, where a < b, MUST NOT depend on the recipient understanding a header that isn't defined in the spec for HTTP/x.a. For example, HTTP/1.0 clients can't be expected to understand chunked encodings, so an HTTP/1.1 server must never send "Transfer-Encoding: chunked" in response to an HTTP/1.0 request 🙅‍♀️

2.3. Which version number to send in a message 🔥

okay this is the most heated debate about HTTP version numbers 😤 It's all about implementations that don't follow the robustness principle and end up producing useless results when they get a message with an HTTP minor version higher than the one they implement. We consider those implementations buggy. But the robustness principle also means message senders should make concessions to buggy implementations when that's truly necessary for things to work 🫶

An HTTP client SHOULD send a request version equal to the highest version it's at least conditionally compliant with, as long as its major version is no higher than the highest version the server supports, if that's known. An HTTP client MUST NOT send a version it isn't at least conditionally compliant with.

An HTTP client MAY send a lower request version if it's known that the server incorrectly implements the HTTP spec, but only after the client has determined that the server is actually buggy.

An HTTP server SHOULD send a response version equal to the highest version it's at least conditionally compliant with, as long as its major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version it isn't at least conditionally compliant with. An HTTP server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request.

An HTTP server MAY send a lower response version if it's known or suspected that the client incorrectly implements the HTTP spec. But this shouldn't be the default, and this SHOULD NOT be done if the request version is HTTP/1.1 or greater. 🌈

5. Authors' addresses ✨

okay bestie, here are the humans who wrote this one 🫶 I'm putting their contact details in exactly as they appear, so you can totally look them up 💅

Jeffrey C. Mogul
Western Research Laboratory
Digital Equipment Corporation
250 University Avenue
Palo Alto, California, 94305, USA
Email: mogul@wrl.dec.com
Roy T. Fielding
Department of Information and Computer Science
University of California
Irvine, CA 92717-3425, USA
Fax: +1 (714) 824-4056
Email: fielding@ics.uci.edu
Jim Gettys
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
Email: jg@w3.org
Henrik Frystyk Nielsen
W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682
Email: frystyk@w3.org

that's the whole cast 🎀 four legends who helped shape how HTTP/1.1 versioning works, and now you know exactly where to find them 🦋🌈

📦 where this page comes from