source: draft-ietf-httpbis/orig/rfc2145.xml @ 311

Last change on this file since 311 was 311, checked in by julian.reschke@…, 11 years ago

Update orig RFCs, also add 2145 and 5234

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