docs/specs/rfc2145.txt

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