source: draft-ietf-httpbis/orig/rfc2145.html @ 1050

Last change on this file since 1050 was 978, checked in by julian.reschke@…, 13 years ago

regen HTML using latest version of xslt
  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/html
File size: 31.4 KB
Line 
1<!DOCTYPE html
2  PUBLIC "-//W3C//DTD HTML 4.01//EN">
3<html lang="en">
4   <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
5      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
6      <title>Use and Interpretation of HTTP Version Numbers</title><style type="text/css" title="Xml2Rfc (sans serif)">
7a {
8  text-decoration: none;
9}
10a.smpl {
11  color: black;
12}
13a:hover {
14  text-decoration: underline;
15}
16a:active {
17  text-decoration: underline;
18}
19address {
20  margin-top: 1em;
21  margin-left: 2em;
22  font-style: normal;
23}
24blockquote {
25  border-style: solid;
26  border-color: gray;
27  border-width: 0 0 0 .25em;
28  font-style: italic;
29  padding-left: 0.5em;
30}
31body {
32  color: black;
33  font-family: verdana, helvetica, arial, sans-serif;
34  font-size: 10pt;
35}
36cite {
37  font-style: normal;
38}
39div.note {
40  margin-left: 2em;
41}
42dd {
43  margin-right: 2em;
44}
45dl {
46  margin-left: 2em;
47}
48
49ul.empty {
50  list-style-type: none;
51}
52ul.empty li {
53  margin-top: .5em;
54}
55dl p {
56  margin-left: 0em;
57}
58dt {
59  margin-top: .5em;
60}
61h1 {
62  font-size: 14pt;
63  line-height: 21pt;
64  page-break-after: avoid;
65}
66h1.np {
67  page-break-before: always;
68}
69h1 a {
70  color: #333333;
71}
72h2 {
73  font-size: 12pt;
74  line-height: 15pt;
75  page-break-after: avoid;
76}
77h3, h4, h5, h6 {
78  font-size: 10pt;
79  page-break-after: avoid;
80}
81h2 a, h3 a, h4 a, h5 a, h6 a {
82  color: black;
83}
84img {
85  margin-left: 3em;
86}
87li {
88  margin-left: 2em;
89  margin-right: 2em;
90}
91ol {
92  margin-left: 2em;
93  margin-right: 2em;
94}
95ol p {
96  margin-left: 0em;
97}
98p {
99  margin-left: 2em;
100  margin-right: 2em;
101}
102pre {
103  margin-left: 3em;
104  background-color: lightyellow;
105  padding: .25em;
106}
107pre.text2 {
108  border-style: dotted;
109  border-width: 1px;
110  background-color: #f0f0f0;
111  width: 69em;
112}
113pre.inline {
114  background-color: white;
115  padding: 0em;
116}
117pre.text {
118  border-style: dotted;
119  border-width: 1px;
120  background-color: #f8f8f8;
121  width: 69em;
122}
123pre.drawing {
124  border-style: solid;
125  border-width: 1px;
126  background-color: #f8f8f8;
127  padding: 2em;
128}
129table {
130  margin-left: 2em;
131}
132table.header {
133  border-spacing: 1px;
134  width: 95%;
135  font-size: 10pt;
136  color: white;
137}
138td.top {
139  vertical-align: top;
140}
141td.topnowrap {
142  vertical-align: top;
143  white-space: nowrap;
144}
145table.header td {
146  background-color: gray;
147  width: 50%;
148}
149td.reference {
150  vertical-align: top;
151  white-space: nowrap;
152  padding-right: 1em;
153}
154thead {
155  display:table-header-group;
156}
157ul.toc {
158  list-style: none;
159  margin-left: 1.5em;
160  margin-right: 0em;
161  padding-left: 0em;
162}
163li.tocline0 {
164  line-height: 150%;
165  font-weight: bold;
166  font-size: 10pt;
167  margin-left: 0em;
168  margin-right: 0em;
169}
170li.tocline1 {
171  line-height: normal;
172  font-weight: normal;
173  font-size: 9pt;
174  margin-left: 0em;
175  margin-right: 0em;
176}
177li.tocline2 {
178  font-size: 0pt;
179}
180ul p {
181  margin-left: 0em;
182}
183.bcp14 {
184  font-style: normal;
185  text-transform: lowercase;
186  font-variant: small-caps;
187}
188blockquote > * .bcp14 {
189  font-style: italic;
190}
191.comment {
192  background-color: yellow;
193}
194.center {
195  text-align: center;
196}
197.error {
198  color: red;
199  font-style: italic;
200  font-weight: bold;
201}
202.figure {
203  font-weight: bold;
204  text-align: center;
205  font-size: 9pt;
206}
207.filename {
208  color: #333333;
209  font-weight: bold;
210  font-size: 12pt;
211  line-height: 21pt;
212  text-align: center;
213}
214.fn {
215  font-weight: bold;
216}
217.hidden {
218  display: none;
219}
220.left {
221  text-align: left;
222}
223.right {
224  text-align: right;
225}
226.title {
227  color: #990000;
228  font-size: 18pt;
229  line-height: 18pt;
230  font-weight: bold;
231  text-align: center;
232  margin-top: 36pt;
233}
234.vcardline {
235  display: block;
236}
237.warning {
238  font-size: 14pt;
239  background-color: yellow;
240}
241
242
243@media print {
244  .noprint {
245    display: none;
246  }
247 
248  a {
249    color: black;
250    text-decoration: none;
251  }
252
253  table.header {
254    width: 90%;
255  }
256
257  td.header {
258    width: 50%;
259    color: black;
260    background-color: white;
261    vertical-align: top;
262    font-size: 12pt;
263  }
264
265  ul.toc a::after {
266    content: leader('.') target-counter(attr(href), page);
267  }
268 
269  a.iref {
270    content: target-counter(attr(href), page);
271  }
272 
273  .print2col {
274    column-count: 2;
275    -moz-column-count: 2;
276    column-fill: auto;
277  }
278}
279
280@page {
281  @top-left {
282       content: "RFC 2145";
283  }
284  @top-right {
285       content: "May 1997";
286  }
287  @top-center {
288       content: "HTTP Version Numbers";
289  }
290  @bottom-left {
291       content: "Mogul, et al.";
292  }
293  @bottom-center {
294       content: "Informational";
295  }
296  @bottom-right {
297       content: "[Page " counter(page) "]";
298  }
299}
300
301@page:first {
302    @top-left {
303      content: normal;
304    }
305    @top-right {
306      content: normal;
307    }
308    @top-center {
309      content: normal;
310    }
311}
312</style><link rel="Contents" href="#rfc.toc">
313      <link rel="Author" href="#rfc.authors">
314      <link rel="Copyright" href="#rfc.copyright">
315      <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
316      <link rel="Chapter" title="2 HTTP version numbers" href="#rfc.section.2">
317      <link rel="Chapter" title="3 Security Considerations" href="#rfc.section.3">
318      <link rel="Chapter" href="#rfc.section.4" title="4 References">
319      <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2145.txt">
320      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2145">
321      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
322      <meta name="keywords" content="HTTP, hypertext transfer protocol">
323      <link rel="schema.dct" href="http://purl.org/dc/terms/">
324      <meta name="dct.creator" content="Mogul, J. C.">
325      <meta name="dct.creator" content="Fielding, R. T.">
326      <meta name="dct.creator" content="Gettys, J.">
327      <meta name="dct.creator" content="Frystyk, H.">
328      <meta name="dct.identifier" content="urn:ietf:rfc:2145">
329      <meta name="dct.issued" scheme="ISO8601" content="1997-05">
330      <meta name="dct.abstract" content="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.">
331      <meta name="dct.isPartOf" content="urn:issn:2070-1721">
332      <meta name="description" content="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.">
333   </head>
334   <body>
335      <table class="header">
336         <tbody>
337            <tr>
338               <td class="left">Network Working Group</td>
339               <td class="right">J. Mogul</td>
340            </tr>
341            <tr>
342               <td class="left">Request for Comments: 2145</td>
343               <td class="right">DEC</td>
344            </tr>
345            <tr>
346               <td class="left">Category: Informational</td>
347               <td class="right">R. Fielding</td>
348            </tr>
349            <tr>
350               <td class="left"></td>
351               <td class="right">UC Irvine</td>
352            </tr>
353            <tr>
354               <td class="left"></td>
355               <td class="right">J. Gettys</td>
356            </tr>
357            <tr>
358               <td class="left"></td>
359               <td class="right">DEC</td>
360            </tr>
361            <tr>
362               <td class="left"></td>
363               <td class="right">H. Frystyk</td>
364            </tr>
365            <tr>
366               <td class="left"></td>
367               <td class="right">MIT/LCS</td>
368            </tr>
369            <tr>
370               <td class="left"></td>
371               <td class="right">May 1997</td>
372            </tr>
373         </tbody>
374      </table>
375      <p class="title">Use and Interpretation of HTTP Version Numbers</p>
376      <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
377      <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
378         of this memo is unlimited.
379      </p>
380      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
381      <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
382      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
383      <p>HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use
384         and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol
385         versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existing
386         HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered
387         definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP.
388      </p>
389      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note</a></h1>
390      <p>Distribution of this document is unlimited. Please send comments to the HTTP working group at &lt;http-wg@cuckoo.hpl.hp.com&gt;.
391         Discussions of the working group are archived at &lt;URL:http://www.ics.uci.edu/pub/ietf/http/&gt;. General discussions about HTTP
392         and the applications which use HTTP should take place on the &lt;www-talk@w3.org&gt; mailing list.
393      </p>
394      <hr class="noprint">
395      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
396      <ul class="toc">
397         <li class="tocline0">1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul class="toc">
398               <li class="tocline1">1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Robustness Principle</a></li>
399            </ul>
400         </li>
401         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP version numbers</a><ul class="toc">
402               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#proxy.behavior">Proxy behavior</a></li>
403               <li class="tocline1">2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Compatibility between minor versions of the same major version</a></li>
404               <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Which version number to send in a message</a></li>
405            </ul>
406         </li>
407         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Security Considerations</a></li>
408         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
409         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#rfc.authors">Authors' Addresses</a></li>
410         <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
411      </ul>
412      <hr class="noprint">
413      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
414      </h1>
415      <p id="rfc.section.1.p.1">HTTP request and response messages include an HTTP protocol version number. According to section <a href="http://tools.ietf.org/html/rfc2068#section-3.1">3.1</a> of the HTTP/1.1 specification <a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[2]</cite></a>,
416      </p>
417      <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2068#section-3.1">
418         <p>HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
419            to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather
420            than the features obtained via that communication. No change is made to the version number for the addition of message components
421            which do not affect communication behavior or which only add to extensible field values. The &lt;minor&gt; number is incremented
422            when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
423            add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
424            of a message within the protocol is changed.
425         </p>
426      </blockquote>
427      <p id="rfc.section.1.p.3">The same language appears in the description of HTTP/1.0 <a href="#RFC1945"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[1]</cite></a>.
428      </p>
429      <p id="rfc.section.1.p.4">Many readers of these documents have expressed some confusion about the intended meaning of this policy. Also, some people
430         who wrote HTTP implementations before RFC1945 <a href="#RFC1945"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[1]</cite></a> was issued were not aware of the intentions behind the introduction of version numbers in HTTP/1.0. This has led to debate
431         and inconsistency regarding the use and interpretation of HTTP version numbers, and has led to interoperability problems in
432         certain cases.
433      </p>
434      <p id="rfc.section.1.p.5">This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existing HTTP/1.0
435         and HTTP/1.1 documents, but it does describe the intention of the authors of those documents. In any case where either of
436         those two documents is ambiguous regarding the use and interpretation of HTTP version numbers, this document should be considered
437         the definitive as to the intentions of the designers of HTTP.
438      </p>
439      <p id="rfc.section.1.p.6">The specification described in this document is not part of the specification of any individual version of HTTP, such as HTTP/1.0
440         or HTTP/1.1. Rather, this document describes the use of HTTP version numbers in any version of HTTP (except for HTTP/0.9,
441         which did not include version numbers).
442      </p>
443      <p id="rfc.section.1.p.7">No vendor or other provider of an HTTP implementation should claim any compliance with any IETF HTTP specification unless
444         the implementation conditionally complies with the rules in this document.
445      </p>
446      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Robustness Principle
447      </h2>
448      <p id="rfc.section.1.1.p.1">RFC791 <a href="#RFC0791"><cite title="Internet Protocol">[4]</cite></a> defines the "robustness principle" in section <a href="http://tools.ietf.org/html/rfc791#section-3.2">3.2</a>:
449      </p>
450      <blockquote id="rfc.section.1.1.p.2" cite="http://tools.ietf.org/html/rfc791#section-3.2">
451         <p>an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.</p>
452      </blockquote>
453      <p id="rfc.section.1.1.p.3">This principle applies to HTTP, as well. It is the fundamental basis for interpreting any part of the HTTP specification that
454         might still be ambiguous. In particular, implementations of HTTP <em class="bcp14">SHOULD NOT</em> reject messages or generate errors unnecessarily.
455      </p>
456      <hr class="noprint">
457      <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;HTTP version numbers
458      </h1>
459      <p id="rfc.section.2.p.1">We start by restating the language quoted above from section <a href="http://tools.ietf.org/html/rfc2068#section-3.1">3.1</a> of the HTTP/1.1 specification <a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[2]</cite></a>:
460      </p>
461      <ul class="empty">
462         <li>It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header
463            does not change between minor versions of the same major version.
464         </li>
465         <li>It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header
466            that it does not understand <em class="bcp14">MUST</em> ignore that header. (The word "ignore" has a special meaning for proxies; see section <a href="#proxy.behavior" title="Proxy behavior">2.1</a> below.)
467         </li>
468      </ul>
469      <p id="rfc.section.2.p.2">To make this as clear as possible: The major version sent in a message <em class="bcp14">MAY</em> indicate the interpretation of other header fields. The minor version sent in a message <em class="bcp14">MUST NOT</em> indicate the interpretation of other header fields. This reflects the principle that the minor version labels the capability
470         of the sender, not the interpretation of the message.
471      </p>
472      <div class="note" id="rfc.section.2.p.3">
473         <p>Note: In a future version of HTTP, we may introduce a mechanism that explicitly requires a receiving implementation to reject
474            a message if it does not understand certain headers. For example, this might be implemented by means of a header that lists
475            a set of other message headers that must be understood by the recipient. Any implementation claiming at least conditional
476            compliance with this future version of HTTP would have to implement this mechanism. However, no implementation claiming compliance
477            with a lower HTTP version (in particular, HTTP/1.1) will have to implement this mechanism.
478         </p> 
479         <p>This future change may be required to support the Protocol Extension Protocol (PEP) <a href="#Kha"><cite title="HTTP/1.2 Extension Protocol (PEP)">[3]</cite></a>.
480         </p>
481      </div>
482      <p id="rfc.section.2.p.4">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
483         unknown) <em class="bcp14">MUST</em> be constructed so that it remains a valid HTTP/1.0 message when all headers not defined in the HTTP/1.0 specification <a href="#RFC1945"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[1]</cite></a> are removed.
484      </p>
485      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="proxy.behavior" href="#proxy.behavior">Proxy behavior</a></h2>
486      <p id="rfc.section.2.1.p.1">A proxy <em class="bcp14">MUST</em> forward an unknown header, unless it is protected by a Connection header. A proxy implementing an HTTP version &gt;= 1.1 <em class="bcp14">MUST NOT</em> forward unknown headers that are protected by a Connection header, as described in section <a href="http://tools.ietf.org/html/rfc2068#section-14.10">14.10</a> of the HTTP/1.1 specification <a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[2]</cite></a>.
487      </p>
488      <p id="rfc.section.2.1.p.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
489         is, an HTTP proxy never "forwards" an HTTP version number in either a request or response.
490      </p>
491      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;Compatibility between minor versions of the same major version
492      </h2>
493      <p id="rfc.section.2.2.p.1">An implementation of HTTP/x.b sending a message to a recipient whose version is known to be HTTP/x.a, a &lt; b, <em class="bcp14">MAY</em> 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"
494         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
495         is an HTTP/1.1 client.
496      </p>
497      <p id="rfc.section.2.2.p.2">An implementation of HTTP/x.b sending a message to a recipient whose version is known to be HTTP/x.a, a &lt; b, <em class="bcp14">MUST NOT</em> depend on the recipient understanding a header not defined in the specification for HTTP/x.a. For example, HTTP/1.0 clients
498         cannot be expected to understand chunked encodings, and so an HTTP/1.1 server must never send "Transfer-Encoding: chunked"
499         in response to an HTTP/1.0 request.
500      </p>
501      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Which version number to send in a message
502      </h2>
503      <p id="rfc.section.2.3.p.1">The most strenuous debate over the use of HTTP version numbers has centered on the problem of implementations that do not
504         follow the robustness principle, and which fail to produce useful results when they receive a message with an HTTP minor version
505         higher than the minor version they implement. We consider these implementations buggy, but we recognize that the robustness
506         principle also implies that message senders should make concessions to buggy implementations when this is truly necessary
507         for interoperation.
508      </p>
509      <p id="rfc.section.2.3.p.2">An HTTP client <em class="bcp14">SHOULD</em> send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major
510         version is no higher than the highest version supported by the server, if this is known. An HTTP client <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant.
511      </p>
512      <p id="rfc.section.2.3.p.3">An HTTP client <em class="bcp14">MAY</em> send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after
513         the client has determined that the server is actually buggy.
514      </p>
515      <p id="rfc.section.2.3.p.4">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major
516         version is less than or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version for which it is not at least conditionally compliant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request.
517      </p>
518      <p id="rfc.section.2.3.p.5">An HTTP server <em class="bcp14">MAY</em> send a lower response version, if it is known or suspected that the client incorrectly implements the HTTP specification,
519         but this should not be the default, and this <em class="bcp14">SHOULD</em> NOT be done if the request version is HTTP/1.1 or greater.
520      </p>
521      <hr class="noprint">
522      <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Security Considerations
523      </h1>
524      <p id="rfc.section.3.p.1">None, except to the extent that security mechanisms introduced in one version of HTTP might depend on the proper interpretation
525         of HTTP version numbers in older implementations.
526      </p>
527      <h1 class="np" id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> References
528      </h1>
529      <table>
530         <tr>
531            <td class="reference"><b id="RFC1945">[1]</b></td>
532            <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
533            </td>
534         </tr> 
535         <tr>
536            <td class="reference"><b id="RFC2068">[2]</b></td>
537            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.
538            </td>
539         </tr> 
540         <tr>
541            <td class="reference"><b id="Kha">[3]</b></td>
542            <td class="top">Khare, R., “HTTP/1.2 Extension Protocol (PEP)”.<br>HTTP Working Group, Work in Progress.
543            </td>
544         </tr> 
545         <tr>
546            <td class="reference"><b id="RFC0791">[4]</b></td>
547            <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc791">Internet Protocol</a>”, RFC&nbsp;791, September&nbsp;1981.
548            </td>
549         </tr>
550      </table>
551      <hr class="noprint">
552      <div class="avoidbreak">
553         <h1 id="rfc.authors" class="np"><a href="#rfc.section.5" id="rfc.section.5">5.</a> <a href="#rfc.authors">Authors' Addresses</a></h1>
554         <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Western Research Laboratory</span><span class="adr"><span class="street-address vcardline">Digital Equipment Corporation</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">California</span>&nbsp;<span class="postal-code">94305</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address>
555         <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">92717-3425</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(714)824-4056"><span class="value">+1 (714) 824-4056</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address>
556         <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">MIT Laboratory for Computer Science</span><span class="adr"><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address>
557         <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">W3 Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address>
558      </div>
559      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
560      <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
561      <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
562         explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
563         restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
564         works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
565         to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
566         in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
567         translate it into languages other than English.
568      </p>
569      <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
570      <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
571         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
572         OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
573         PURPOSE.
574      </p>
575      <hr class="noprint">
576      <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
577      <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
578         to pertain to the implementation or use of the technology described in this document or the extent to which any license under
579         such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
580         Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
581         found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
582         or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
583         or users of this specification can be obtained from the IETF Secretariat.
584      </p>
585      <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
586         rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
587         Executive Director.
588      </p>
589   </body>
590</html>
Note: See TracBrowser for help on using the repository browser.