2004/id/draft-ietf-http-versions-00.txt


HTTP Working Group                                      J. C. Mogul, DEC
Internet-Draft                                    R. Fielding, UC Irvine
Expires: 30 July 1997                                     J. Gettys, DEC
                                                     H. Frystyk, MIT/LCS
                                                         22 January 1997
                       Use and interpretation of
                          HTTP version numbers

                    draft-ietf-http-versions-00.txt


STATUS OF THIS MEMO

        This document is an Internet-Draft. Internet-Drafts are
        working documents of the Internet Engineering Task Force
        (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as
        Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress."

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.


ABSTRACT

        HTTP request and response messages include an HTTP protocol
        version number.  Some confusion exists concerning the
        proper use and interpretation of HTTP version numbers, and
        concerning interoperability of HTTP implementations of
        different protocol versions.  This document is an attempt
        to clarify the situation.  It is not a modification of the
        intended meaning of the existing HTTP/1.0 and HTTP/1.1
        documents, but it does describe the intention of the
        authors of those documents, and can be considered
        definitive when there is any ambiguity in those documents
        concerning HTTP version numbers, for all versions of HTTP.

Mogul et al.                                                    [Page 1]

Internet-Draft            HTTP version numbers     22 January 1997 12:26


                           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        4
         version
     2.3 Which version number to send in a message                     4
3 Security Considerations                                              5
4 References                                                           5
5 Authors' addresses                                                   6


1 Introduction

   HTTP request and response messages include an HTTP protocol version
   number.  According to section 3.1 of the HTTP/1.1 specification [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.

   The same language appears in the description of HTTP/1.0 [1].

   Many readers of these documents have expressed some confusion about
   the intended meaning of this policy.  Also, some people who wrote
   HTTP implementations before RFC1945 [1] was issued were not aware of
   the intentions behind the introduction of version numbers in
   HTTP/1.0.  This has led to debate and inconsistency regarding the use
   and interpretation of HTTP version numbers, and has led to
   interoperability problems in certain cases.

   This document is an attempt to clarify the situation.  It is not a
   modification of the intended meaning of the existing HTTP/1.0 and
   HTTP/1.1 documents, but it does describe the intention of the authors
   of those documents.  In any case where either of those two documents
   is ambiguous regarding the use and interpretation of HTTP version
   numbers, this document should be considered the definitive as to the
   intentions of the designers of HTTP.

Mogul et al.                                                    [Page 2]

Internet-Draft            HTTP version numbers     22 January 1997 12:26


   The specification described in this document is not part of the
   specification of any individual version of HTTP, such as HTTP/1.0 or
   HTTP/1.1.  Rather, this document describes the use of HTTP version
   numbers in any version of HTTP (except for HTTP/0.9, which did not
   include version numbers).

   No vendor or other provider of an HTTP implementation should claim
   any compliance with any IETF HTTP specification unless the
   implementation conditionally complies with the rules in this
   document.

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, as well.  It is the fundamental basis
   for interpreting any part of the HTTP specification that might still
   be ambiguous.  In particular, implementations of HTTP SHOULD NOT
   reject messages or generate errors unnecessarily.


2 HTTP version numbers

   We start by restating the language quoted above from section 3.1 of
   the HTTP/1.1 specification [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.)

          It is, and has always been, the explicit intent of the
       HTTP specification that if an implementation receives a
       message header whose major version number is greater than
       that of the implementation, it MUST NOT accept that message.

   To make this as clear as possible:  The major version sent in a
   message MAY indicate the interpretation of other header fields.  The
   minor version sent in a message MUST NOT indicate the interpretation
   of other header fields.  This reflects the principle that the minor
   version labels the capability of the sender, not the interpretation
   of the message.


Mogul et al.                                                    [Page 3]

Internet-Draft            HTTP version numbers     22 January 1997 12:26


      Note: In a future version of HTTP, we may introduce a mechanism
      that explicitly requires a receiving implementation to reject a
      message if it does not understand certain headers.  For
      example, this might be implemented by means of a header that
      lists a set of other message headers that must be understood by
      the recipient.  Any implementation claiming at least
      conditional compliance with this 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 these rules is that an HTTP/1.1 message sent to an
   HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
   constructed so that it remains a valid HTTP/1.0 message when all
   headers not defined in the HTTP/1.0 specification [1] are removed.

2.1 Proxy behavior
   A proxy MUST forward an unknown header, unless it 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
   specification [2].

   We remind the reader that that HTTP version numbers are hop-by-hop
   components of HTTP messages, and are not end-to-end.  That is, an
   HTTP proxy never ``forwards'' an HTTP version number in either a
   request or 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, a < b, MAY send a header that is not
   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;
   this may be useful if 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, a < b, MUST NOT depend on the
   recipient understanding a header not defined in the specification for
   HTTP/x.a.  For example, HTTP/1.0 clients cannot be expected to
   understand chunked encodings, and 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
   The most strenuous debate over the use of HTTP version numbers has
   centered on the problem of implementations that do not follow the
   robustness principle, and which fail to produce useful results when

Mogul et al.                                                    [Page 4]

Internet-Draft            HTTP version numbers     22 January 1997 12:26


   they receive a message with an HTTP minor version higher than the
   minor version they implement.  We consider these implementations
   buggy, but we recognize that the robustness principle also implies
   that message senders should make concessions to buggy implementations
   when this is truly necessary for interoperation.

   An HTTP client SHOULD send a request version equal to the highest
   version for which the client is at least conditionally compliant, and
   whose major version is no higher than the highest version supported
   by the server, if this is known.  An HTTP client MUST NOT send a
   version for which it is not at least conditionally compliant.

   An HTTP client MAY send a lower request version, if it is known that
   the server incorrectly implements the HTTP specification, 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 for which the server is at least conditionally compliant, and
   whose major version is equal to the one received in the request.  An
   HTTP server MUST NOT send a version for which it is not at least
   conditionally compliant.

   An HTTP server MAY send a lower response version, if it is known or
   suspected that the client incorrectly implements the HTTP
   specification, but this should not be the default, and this SHOULD
   NOT be done if the request version is HTTP/1.1 or greater.


3 Security Considerations

   None, except to the extent that security mechanisms introduced in one
   version of HTTP might depend on the proper interpretation of HTTP
   version numbers in older implementations.


4 References

   1.  T. Berners-Lee, R. Fielding, and H. Frystyk.  Hypertext Transfer
   Protocol -- HTTP/1.0.  RFC 1945, HTTP Working Group, May, 1996.

   2.  Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
   Nielsen, and Tim Berners-Lee.  Hypertext Transfer Protocol --
   HTTP/1.1.  RFC 2068, HTTP Working Group, January, 1997.

   3.  Rohit Khare.  HTTP/1.2 Extension Protocol (PEP).  Internet Draft
   draft-ietf-http-pep-00, HTTP Working Group, August, 1996. This is a
   work in progress.

   4.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.


Mogul et al.                                                    [Page 5]

Internet-Draft            HTTP version numbers     22 January 1997 12:26


5 Authors' addresses

   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


Mogul et al.                                                    [Page 6]
1
2	HTTP Working Group J. C. Mogul, DEC
3	Internet-Draft R. Fielding, UC Irvine
4	Expires: 30 July 1997 J. Gettys, DEC
5	H. Frystyk, MIT/LCS
6	22 January 1997
7	Use and interpretation of
8	HTTP version numbers
9
10	draft-ietf-http-versions-00.txt
11
12
13	STATUS OF THIS MEMO
14
15	This document is an Internet-Draft. Internet-Drafts are
16	working documents of the Internet Engineering Task Force
17	(IETF), its areas, and its working groups. Note that other
18	groups may also distribute working documents as
19	Internet-Drafts.
20
21	Internet-Drafts are draft documents valid for a maximum of
22	six months and may be updated, replaced, or obsoleted by
23	other documents at any time. It is inappropriate to use
24	Internet-Drafts as reference material or to cite them other
25	than as "work in progress."
26
27	To learn the current status of any Internet-Draft, please
28	check the "1id-abstracts.txt" listing contained in the
29	Internet-Drafts Shadow Directories on ftp.is.co.za
30	(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
31	Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
32	West Coast).
33
34	Distribution of this document is unlimited. Please send
35	comments to the HTTP working group at
36	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
37	group are archived at
38	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
39	discussions about HTTP and the applications which use HTTP
40	should take place on the <www-talk@w3.org> mailing list.
41
42
43	ABSTRACT
44
45	HTTP request and response messages include an HTTP protocol
46	version number. Some confusion exists concerning the
47	proper use and interpretation of HTTP version numbers, and
48	concerning interoperability of HTTP implementations of
49	different protocol versions. This document is an attempt
50	to clarify the situation. It is not a modification of the
51	intended meaning of the existing HTTP/1.0 and HTTP/1.1
52	documents, but it does describe the intention of the
53	authors of those documents, and can be considered
54	definitive when there is any ambiguity in those documents
55	concerning HTTP version numbers, for all versions of HTTP.
56
57	Mogul et al. [Page 1]
58
59	Internet-Draft HTTP version numbers 22 January 1997 12:26
60
61
62	TABLE OF CONTENTS
63
64	1 Introduction 2
65	1.1 Robustness Principle 3
66	2 HTTP version numbers 3
67	2.1 Proxy behavior 4
68	2.2 Compatibility between minor versions of the same major 4
69	version
70	2.3 Which version number to send in a message 4
71	3 Security Considerations 5
72	4 References 5
73	5 Authors' addresses 6
74
75
76	1 Introduction
77
78	HTTP request and response messages include an HTTP protocol version
79	number. According to section 3.1 of the HTTP/1.1 specification [2],
80
81	HTTP uses a "<major>.<minor>" numbering scheme to indicate
82	versions of the protocol. The protocol versioning policy is
83	intended to allow the sender to indicate the format of a
84	message and its capacity for understanding further HTTP
85	communication, rather than the features obtained via that
86	communication. No change is made to the version number for
87	the addition of message components which do not affect
88	communication behavior or which only add to extensible field
89	values. The <minor> number is incremented when the changes
90	made to the protocol add features which do not change the
91	general message parsing algorithm, but which may add to the
92	message semantics and imply additional capabilities of the
93	sender. The <major> number is incremented when the format of
94	a message within the protocol is changed.
95
96	The same language appears in the description of HTTP/1.0 [1].
97
98	Many readers of these documents have expressed some confusion about
99	the intended meaning of this policy. Also, some people who wrote
100	HTTP implementations before RFC1945 [1] was issued were not aware of
101	the intentions behind the introduction of version numbers in
102	HTTP/1.0. This has led to debate and inconsistency regarding the use
103	and interpretation of HTTP version numbers, and has led to
104	interoperability problems in certain cases.
105
106	This document is an attempt to clarify the situation. It is not a
107	modification of the intended meaning of the existing HTTP/1.0 and
108	HTTP/1.1 documents, but it does describe the intention of the authors
109	of those documents. In any case where either of those two documents
110	is ambiguous regarding the use and interpretation of HTTP version
111	numbers, this document should be considered the definitive as to the
112	intentions of the designers of HTTP.
113
114	Mogul et al. [Page 2]
115
116	Internet-Draft HTTP version numbers 22 January 1997 12:26
117
118
119	The specification described in this document is not part of the
120	specification of any individual version of HTTP, such as HTTP/1.0 or
121	HTTP/1.1. Rather, this document describes the use of HTTP version
122	numbers in any version of HTTP (except for HTTP/0.9, which did not
123	include version numbers).
124
125	No vendor or other provider of an HTTP implementation should claim
126	any compliance with any IETF HTTP specification unless the
127	implementation conditionally complies with the rules in this
128	document.
129
130	1.1 Robustness Principle
131	RFC791 [4] defines the ``robustness principle'' in section 3.2:
132
133	an implementation must be conservative in its sending
134	behavior, and liberal in its receiving behavior.
135
136	This principle applies to HTTP, as well. It is the fundamental basis
137	for interpreting any part of the HTTP specification that might still
138	be ambiguous. In particular, implementations of HTTP SHOULD NOT
139	reject messages or generate errors unnecessarily.
140
141
142	2 HTTP version numbers
143
144	We start by restating the language quoted above from section 3.1 of
145	the HTTP/1.1 specification [2]:
146
147	It is, and has always been, the explicit intent of the
148	HTTP specification that the interpretation of an HTTP message
149	header does not change between minor versions of the same
150	major version.
151
152	It is, and has always been, the explicit intent of the
153	HTTP specification that an implementation receiving a message
154	header that it does not understand MUST ignore that header.
155	(The word ``ignore'' has a special meaning for proxies; see
156	section 2.1 below.)
157
158	It is, and has always been, the explicit intent of the
159	HTTP specification that if an implementation receives a
160	message header whose major version number is greater than
161	that of the implementation, it MUST NOT accept that message.
162
163	To make this as clear as possible: The major version sent in a
164	message MAY indicate the interpretation of other header fields. The
165	minor version sent in a message MUST NOT indicate the interpretation
166	of other header fields. This reflects the principle that the minor
167	version labels the capability of the sender, not the interpretation
168	of the message.
169
170
171	Mogul et al. [Page 3]
172
173	Internet-Draft HTTP version numbers 22 January 1997 12:26
174
175
176	Note: In a future version of HTTP, we may introduce a mechanism
177	that explicitly requires a receiving implementation to reject a
178	message if it does not understand certain headers. For
179	example, this might be implemented by means of a header that
180	lists a set of other message headers that must be understood by
181	the recipient. Any implementation claiming at least
182	conditional compliance with this future version of HTTP would
183	have to implement this mechanism. However, no implementation
184	claiming compliance with a lower HTTP version (in particular,
185	HTTP/1.1) will have to implement this mechanism.
186
187	This future change may be required to support the Protocol
188	Extension Protocol (PEP) [3].
189
190	One consequence of these rules is that an HTTP/1.1 message sent to an
191	HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
192	constructed so that it remains a valid HTTP/1.0 message when all
193	headers not defined in the HTTP/1.0 specification [1] are removed.
194
195	2.1 Proxy behavior
196	A proxy MUST forward an unknown header, unless it is protected by a
197	Connection header. A proxy implementing an HTTP version >= 1.1 MUST
198	NOT forward unknown headers that are protected by a Connection
199	header, as described in section 14.10 of the HTTP/1.1
200	specification [2].
201
202	We remind the reader that that HTTP version numbers are hop-by-hop
203	components of HTTP messages, and are not end-to-end. That is, an
204	HTTP proxy never ``forwards'' an HTTP version number in either a
205	request or response.
206
207	2.2 Compatibility between minor versions of the same major version
208	An implementation of HTTP/x.b sending a message to a recipient whose
209	version is known to be HTTP/x.a, a < b, MAY send a header that is not
210	defined in the specification for HTTP/x.a. For example, an HTTP/1.1
211	server may send a ``Cache-control'' header to an HTTP/1.0 client;
212	this may be useful if the immediate recipient is an HTTP/1.0 proxy,
213	but the ultimate recipient is an HTTP/1.1 client.
214
215	An implementation of HTTP/x.b sending a message to a recipient whose
216	version is known to be HTTP/x.a, a < b, MUST NOT depend on the
217	recipient understanding a header not defined in the specification for
218	HTTP/x.a. For example, HTTP/1.0 clients cannot be expected to
219	understand chunked encodings, and so an HTTP/1.1 server must never
220	send ``Transfer-Encoding: chunked'' in response to an HTTP/1.0
221	request.
222
223	2.3 Which version number to send in a message
224	The most strenuous debate over the use of HTTP version numbers has
225	centered on the problem of implementations that do not follow the
226	robustness principle, and which fail to produce useful results when
227
228	Mogul et al. [Page 4]
229
230	Internet-Draft HTTP version numbers 22 January 1997 12:26
231
232
233	they receive a message with an HTTP minor version higher than the
234	minor version they implement. We consider these implementations
235	buggy, but we recognize that the robustness principle also implies
236	that message senders should make concessions to buggy implementations
237	when this is truly necessary for interoperation.
238
239	An HTTP client SHOULD send a request version equal to the highest
240	version for which the client is at least conditionally compliant, and
241	whose major version is no higher than the highest version supported
242	by the server, if this is known. An HTTP client MUST NOT send a
243	version for which it is not at least conditionally compliant.
244
245	An HTTP client MAY send a lower request version, if it is known that
246	the server incorrectly implements the HTTP specification, but only
247	after the client has determined that the server is actually buggy.
248
249	An HTTP server SHOULD send a response version equal to the highest
250	version for which the server is at least conditionally compliant, and
251	whose major version is equal to the one received in the request. An
252	HTTP server MUST NOT send a version for which it is not at least
253	conditionally compliant.
254
255	An HTTP server MAY send a lower response version, if it is known or
256	suspected that the client incorrectly implements the HTTP
257	specification, but this should not be the default, and this SHOULD
258	NOT be done if the request version is HTTP/1.1 or greater.
259
260
261	3 Security Considerations
262
263	None, except to the extent that security mechanisms introduced in one
264	version of HTTP might depend on the proper interpretation of HTTP
265	version numbers in older implementations.
266
267
268	4 References
269
270	1. T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer
271	Protocol -- HTTP/1.0. RFC 1945, HTTP Working Group, May, 1996.
272
273	2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk
274	Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol --
275	HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997.
276
277	3. Rohit Khare. HTTP/1.2 Extension Protocol (PEP). Internet Draft
278	draft-ietf-http-pep-00, HTTP Working Group, August, 1996. This is a
279	work in progress.
280
281	4. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981.
282
283
284
285	Mogul et al. [Page 5]
286
287	Internet-Draft HTTP version numbers 22 January 1997 12:26
288
289
290	5 Authors' addresses
291
292	Jeffrey C. Mogul
293	Western Research Laboratory
294	Digital Equipment Corporation
295	250 University Avenue
296	Palo Alto, California, 94305, USA
297	Email: mogul@wrl.dec.com
298
299	Roy T. Fielding
300	Department of Information and Computer Science
301	University of California
302	Irvine, CA 92717-3425, USA
303	Fax: +1 (714) 824-4056
304	Email: fielding@ics.uci.edu
305
306	Jim Gettys
307	MIT Laboratory for Computer Science
308	545 Technology Square
309	Cambridge, MA 02139, USA
310	Fax: +1 (617) 258 8682
311	Email: jg@w3.org
312
313	Henrik Frystyk Nielsen
314	W3 Consortium
315	MIT Laboratory for Computer Science
316	545 Technology Square
317	Cambridge, MA 02139, USA
318	Fax: +1 (617) 258 8682
319	Email: frystyk@w3.org
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342	Mogul et al. [Page 6]