← Back to branch summary

~rdoering/ubuntu/karmic/erlang/fix-535090

« back to all changes in this revision

Viewing changes to lib/inets/doc/archive/rfc2145.txt

  • Committer: Bazaar Package Importer
  • Author(s): Sergei Golovan
  • Date: 2009-05-07 15:07:37 UTC
  • mfrom: (3.3.1 squeeze)
  • Revision ID: james.westby@ubuntu.com-20090507150737-x1m1n2qovms1zsk0
Tags: 1:13.b-dfsg1-1
http://bugs.debian.org/527053
http://bugs.debian.org/526682
http://bugs.debian.org/526627
* Removed another bunch of non-free RFCs from original tarball
  (closes: #527053).
* Fixed build-dependencies list by adding missing comma. This requires
  libsctp-dev again. Also, added libsctp1 dependency to erlang-base and
  erlang-base-hipe packages because the shared library is loaded via
  dlopen now and cannot be added using dh_slibdeps (closes: #526682).
* Weakened dependency of erlang-webtool on erlang-observer to recommends
  to avoid circular dependencies (closes: #526627).
* Added solaris-i386 to HiPE enabled architectures.
* Made script sources in /usr/lib/erlang/erts-*/bin directory executable,
  which is more convenient if a user wants to create a target Erlang system.
* Shortened extended description line for erlang-dev package to make it
  fit 80x25 terminals.

Show diffs side-by-side

added added

removed removed

Lines of Context:
lib/inets/doc/archive/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
 
 
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
 
 
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
 
 
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
 
 
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
 
 
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
 
 
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