idnits 2.17.1 draft-ietf-http-versions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '...ar, implementations of HTTP SHOULD NOT...' RFC 2119 keyword, line 143: '...s not understand MUST ignore that head...' RFC 2119 keyword, line 150: '...plementation, it MUST NOT accept that ...' RFC 2119 keyword, line 153: '... message MAY indicate the interpreta...' RFC 2119 keyword, line 154: '...ent in a message MUST NOT indicate the...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 January 1997) is 9949 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 185 looks like a reference -- Missing reference section? '1' on line 178 looks like a reference -- Missing reference section? '4' on line 121 looks like a reference -- Missing reference section? '3' on line 173 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 HTTP Working Group J. C. Mogul, DEC 2 Internet-Draft R. Fielding, UC Irvine 3 Expires: 30 July 1997 J. Gettys, DEC 4 H. Frystyk, MIT/LCS 5 22 January 1997 6 Use and interpretation of 7 HTTP version numbers 9 draft-ietf-http-versions-00.txt 11 STATUS OF THIS MEMO 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as "work in progress." 25 To learn the current status of any Internet-Draft, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za 28 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 29 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 30 West Coast). 32 Distribution of this document is unlimited. Please send 33 comments to the HTTP working group at 34 . Discussions of the working 35 group are archived at 36 . General 37 discussions about HTTP and the applications which use HTTP 38 should take place on the mailing list. 40 ABSTRACT 42 HTTP request and response messages include an HTTP protocol 43 version number. Some confusion exists concerning the 44 proper use and interpretation of HTTP version numbers, and 45 concerning interoperability of HTTP implementations of 46 different protocol versions. This document is an attempt 47 to clarify the situation. It is not a modification of the 48 intended meaning of the existing HTTP/1.0 and HTTP/1.1 49 documents, but it does describe the intention of the 50 authors of those documents, and can be considered 51 definitive when there is any ambiguity in those documents 52 concerning HTTP version numbers, for all versions of HTTP. 54 Internet-Draft HTTP version numbers 22 January 1997 12:26 56 TABLE OF CONTENTS 58 1 Introduction 2 59 1.1 Robustness Principle 3 60 2 HTTP version numbers 3 61 2.1 Proxy behavior 4 62 2.2 Compatibility between minor versions of the same major 4 63 version 64 2.3 Which version number to send in a message 4 65 3 Security Considerations 5 66 4 References 5 67 5 Authors' addresses 6 69 1 Introduction 71 HTTP request and response messages include an HTTP protocol version 72 number. According to section 3.1 of the HTTP/1.1 specification [2], 74 HTTP uses a "." numbering scheme to indicate 75 versions of the protocol. The protocol versioning policy is 76 intended to allow the sender to indicate the format of a 77 message and its capacity for understanding further HTTP 78 communication, rather than the features obtained via that 79 communication. No change is made to the version number for 80 the addition of message components which do not affect 81 communication behavior or which only add to extensible field 82 values. The number is incremented when the changes 83 made to the protocol add features which do not change the 84 general message parsing algorithm, but which may add to the 85 message semantics and imply additional capabilities of the 86 sender. The number is incremented when the format of 87 a message within the protocol is changed. 89 The same language appears in the description of HTTP/1.0 [1]. 91 Many readers of these documents have expressed some confusion about 92 the intended meaning of this policy. Also, some people who wrote 93 HTTP implementations before RFC1945 [1] was issued were not aware of 94 the intentions behind the introduction of version numbers in 95 HTTP/1.0. This has led to debate and inconsistency regarding the use 96 and interpretation of HTTP version numbers, and has led to 97 interoperability problems in certain cases. 99 This document is an attempt to clarify the situation. It is not a 100 modification of the intended meaning of the existing HTTP/1.0 and 101 HTTP/1.1 documents, but it does describe the intention of the authors 102 of those documents. In any case where either of those two documents 103 is ambiguous regarding the use and interpretation of HTTP version 104 numbers, this document should be considered the definitive as to the 105 intentions of the designers of HTTP. 107 Internet-Draft HTTP version numbers 22 January 1997 12:26 109 The specification described in this document is not part of the 110 specification of any individual version of HTTP, such as HTTP/1.0 or 111 HTTP/1.1. Rather, this document describes the use of HTTP version 112 numbers in any version of HTTP (except for HTTP/0.9, which did not 113 include version numbers). 115 No vendor or other provider of an HTTP implementation should claim 116 any compliance with any IETF HTTP specification unless the 117 implementation conditionally complies with the rules in this 118 document. 120 1.1 Robustness Principle 121 RFC791 [4] defines the ``robustness principle'' in section 3.2: 123 an implementation must be conservative in its sending 124 behavior, and liberal in its receiving behavior. 126 This principle applies to HTTP, as well. It is the fundamental basis 127 for interpreting any part of the HTTP specification that might still 128 be ambiguous. In particular, implementations of HTTP SHOULD NOT 129 reject messages or generate errors unnecessarily. 131 2 HTTP version numbers 133 We start by restating the language quoted above from section 3.1 of 134 the HTTP/1.1 specification [2]: 136 It is, and has always been, the explicit intent of the 137 HTTP specification that the interpretation of an HTTP message 138 header does not change between minor versions of the same 139 major version. 141 It is, and has always been, the explicit intent of the 142 HTTP specification that an implementation receiving a message 143 header that it does not understand MUST ignore that header. 144 (The word ``ignore'' has a special meaning for proxies; see 145 section 2.1 below.) 147 It is, and has always been, the explicit intent of the 148 HTTP specification that if an implementation receives a 149 message header whose major version number is greater than 150 that of the implementation, it MUST NOT accept that message. 152 To make this as clear as possible: The major version sent in a 153 message MAY indicate the interpretation of other header fields. The 154 minor version sent in a message MUST NOT indicate the interpretation 155 of other header fields. This reflects the principle that the minor 156 version labels the capability of the sender, not the interpretation 157 of the message. 159 Internet-Draft HTTP version numbers 22 January 1997 12:26 161 Note: In a future version of HTTP, we may introduce a mechanism 162 that explicitly requires a receiving implementation to reject a 163 message if it does not understand certain headers. For 164 example, this might be implemented by means of a header that 165 lists a set of other message headers that must be understood by 166 the recipient. Any implementation claiming at least 167 conditional compliance with this future version of HTTP would 168 have to implement this mechanism. However, no implementation 169 claiming compliance with a lower HTTP version (in particular, 170 HTTP/1.1) will have to implement this mechanism. 172 This future change may be required to support the Protocol 173 Extension Protocol (PEP) [3]. 175 One consequence of these rules is that an HTTP/1.1 message sent to an 176 HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be 177 constructed so that it remains a valid HTTP/1.0 message when all 178 headers not defined in the HTTP/1.0 specification [1] are removed. 180 2.1 Proxy behavior 181 A proxy MUST forward an unknown header, unless it is protected by a 182 Connection header. A proxy implementing an HTTP version >= 1.1 MUST 183 NOT forward unknown headers that are protected by a Connection 184 header, as described in section 14.10 of the HTTP/1.1 185 specification [2]. 187 We remind the reader that that HTTP version numbers are hop-by-hop 188 components of HTTP messages, and are not end-to-end. That is, an 189 HTTP proxy never ``forwards'' an HTTP version number in either a 190 request or response. 192 2.2 Compatibility between minor versions of the same major version 193 An implementation of HTTP/x.b sending a message to a recipient whose 194 version is known to be HTTP/x.a, a < b, MAY send a header that is not 195 defined in the specification for HTTP/x.a. For example, an HTTP/1.1 196 server may send a ``Cache-control'' header to an HTTP/1.0 client; 197 this may be useful if the immediate recipient is an HTTP/1.0 proxy, 198 but the ultimate recipient is an HTTP/1.1 client. 200 An implementation of HTTP/x.b sending a message to a recipient whose 201 version is known to be HTTP/x.a, a < b, MUST NOT depend on the 202 recipient understanding a header not defined in the specification for 203 HTTP/x.a. For example, HTTP/1.0 clients cannot be expected to 204 understand chunked encodings, and so an HTTP/1.1 server must never 205 send ``Transfer-Encoding: chunked'' in response to an HTTP/1.0 206 request. 208 2.3 Which version number to send in a message 209 The most strenuous debate over the use of HTTP version numbers has 210 centered on the problem of implementations that do not follow the 211 robustness principle, and which fail to produce useful results when 213 Internet-Draft HTTP version numbers 22 January 1997 12:26 215 they receive a message with an HTTP minor version higher than the 216 minor version they implement. We consider these implementations 217 buggy, but we recognize that the robustness principle also implies 218 that message senders should make concessions to buggy implementations 219 when this is truly necessary for interoperation. 221 An HTTP client SHOULD send a request version equal to the highest 222 version for which the client is at least conditionally compliant, and 223 whose major version is no higher than the highest version supported 224 by the server, if this is known. An HTTP client MUST NOT send a 225 version for which it is not at least conditionally compliant. 227 An HTTP client MAY send a lower request version, if it is known that 228 the server incorrectly implements the HTTP specification, but only 229 after the client has determined that the server is actually buggy. 231 An HTTP server SHOULD send a response version equal to the highest 232 version for which the server is at least conditionally compliant, and 233 whose major version is equal to the one received in the request. An 234 HTTP server MUST NOT send a version for which it is not at least 235 conditionally compliant. 237 An HTTP server MAY send a lower response version, if it is known or 238 suspected that the client incorrectly implements the HTTP 239 specification, but this should not be the default, and this SHOULD 240 NOT be done if the request version is HTTP/1.1 or greater. 242 3 Security Considerations 244 None, except to the extent that security mechanisms introduced in one 245 version of HTTP might depend on the proper interpretation of HTTP 246 version numbers in older implementations. 248 4 References 250 1. T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer 251 Protocol -- HTTP/1.0. RFC 1945, HTTP Working Group, May, 1996. 253 2. Roy T. Fielding, Jim Gettys, Jeffrey C. Mogul, Henrik Frystyk 254 Nielsen, and Tim Berners-Lee. Hypertext Transfer Protocol -- 255 HTTP/1.1. RFC 2068, HTTP Working Group, January, 1997. 257 3. Rohit Khare. HTTP/1.2 Extension Protocol (PEP). Internet Draft 258 draft-ietf-http-pep-00, HTTP Working Group, August, 1996. This is a 259 work in progress. 261 4. Jon Postel. Internet Protocol. RFC 791, NIC, September, 1981. 263 Internet-Draft HTTP version numbers 22 January 1997 12:26 265 5 Authors' addresses 267 Jeffrey C. Mogul 268 Western Research Laboratory 269 Digital Equipment Corporation 270 250 University Avenue 271 Palo Alto, California, 94305, USA 272 Email: mogul@wrl.dec.com 274 Roy T. Fielding 275 Department of Information and Computer Science 276 University of California 277 Irvine, CA 92717-3425, USA 278 Fax: +1 (714) 824-4056 279 Email: fielding@ics.uci.edu 281 Jim Gettys 282 MIT Laboratory for Computer Science 283 545 Technology Square 284 Cambridge, MA 02139, USA 285 Fax: +1 (617) 258 8682 286 Email: jg@w3.org 288 Henrik Frystyk Nielsen 289 W3 Consortium 290 MIT Laboratory for Computer Science 291 545 Technology Square 292 Cambridge, MA 02139, USA 293 Fax: +1 (617) 258 8682 294 Email: frystyk@w3.org