Ignore:
Timestamp:
Jan 19, 2014, 11:43:53 PM (6 years ago)
Author:
julian.reschke@…
Message:

update rfc2617.xml (ABNF alignment was off from published version), regen all HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/orig/rfc2145.html

    r1305 r2564  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    66      <title>Use and Interpretation of HTTP Version Numbers</title><style type="text/css" title="Xml2Rfc (sans serif)">
     
    3131body {
    3232  color: black;
    33   font-family: verdana, helvetica, arial, sans-serif;
    34   font-size: 10pt;
     33  font-family: cambria, helvetica, arial, sans-serif;
     34  font-size: 11pt;
     35  margin-right: 2em;
    3536}
    3637cite {
     
    4041  margin-left: 2em;
    4142}
    42 dd {
    43   margin-right: 2em;
    44 }
    4543dl {
    4644  margin-left: 2em;
    4745}
    48 
    4946ul.empty {
    5047  list-style-type: none;
     
    6057}
    6158h1 {
    62   font-size: 14pt;
     59  font-size: 130%;
    6360  line-height: 21pt;
    6461  page-break-after: avoid;
     
    6764  page-break-before: always;
    6865}
    69 h1 a {
    70   color: #333333;
    71 }
    7266h2 {
    73   font-size: 12pt;
     67  font-size: 120%;
    7468  line-height: 15pt;
    7569  page-break-after: avoid;
    7670}
    77 h3, h4, h5, h6 {
    78   font-size: 10pt;
     71h3 {
     72  font-size: 110%;
    7973  page-break-after: avoid;
    8074}
    81 h2 a, h3 a, h4 a, h5 a, h6 a {
     75h4, h5, h6 {
     76  page-break-after: avoid;
     77}
     78h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    8279  color: black;
    8380}
     
    8784li {
    8885  margin-left: 2em;
    89   margin-right: 2em;
    9086}
    9187ol {
    9288  margin-left: 2em;
    93   margin-right: 2em;
    9489}
    9590ol.la {
     
    10499p {
    105100  margin-left: 2em;
    106   margin-right: 2em;
    107101}
    108102pre {
     
    110104  background-color: lightyellow;
    111105  padding: .25em;
     106  page-break-inside: avoid;
    112107}
    113108pre.text2 {
     
    139134  border-spacing: 1px;
    140135  width: 95%;
    141   font-size: 10pt;
     136  font-size: 11pt;
    142137  color: white;
    143138}
     
    147142td.topnowrap {
    148143  vertical-align: top;
    149   white-space: nowrap; 
     144  white-space: nowrap;
    150145}
    151146table.header td {
     
    164159  list-style: none;
    165160  margin-left: 1.5em;
    166   margin-right: 0em;
    167161  padding-left: 0em;
    168162}
     
    170164  line-height: 150%;
    171165  font-weight: bold;
    172   font-size: 10pt;
    173166  margin-left: 0em;
    174   margin-right: 0em;
    175167}
    176168ul.toc li li {
    177169  line-height: normal;
    178170  font-weight: normal;
    179   font-size: 9pt;
     171  font-size: 10pt;
    180172  margin-left: 0em;
    181   margin-right: 0em;
    182173}
    183174li.excluded {
     
    186177ul p {
    187178  margin-left: 0em;
     179}
     180.title, .filename, h1, h2, h3, h4 {
     181  font-family: candara, helvetica, arial, sans-serif;
     182}
     183samp, tt, code, pre {
     184  font: consolas, monospace;
    188185}
    189186.bcp14 {
     
    209206  font-weight: bold;
    210207  text-align: center;
    211   font-size: 9pt;
     208  font-size: 10pt;
    212209}
    213210.filename {
    214211  color: #333333;
     212  font-size: 75%;
    215213  font-weight: bold;
    216   font-size: 12pt;
    217214  line-height: 21pt;
    218215  text-align: center;
     
    221218  font-weight: bold;
    222219}
    223 .hidden {
    224   display: none;
    225 }
    226220.left {
    227221  text-align: left;
     
    231225}
    232226.title {
    233   color: #990000;
    234   font-size: 18pt;
     227  color: green;
     228  font-size: 150%;
    235229  line-height: 18pt;
    236230  font-weight: bold;
     
    238232  margin-top: 36pt;
    239233}
    240 .vcardline {
    241   display: block;
    242 }
    243234.warning {
    244   font-size: 14pt;
     235  font-size: 130%;
    245236  background-color: yellow;
    246237}
     
    251242    display: none;
    252243  }
    253  
     244
    254245  a {
    255246    color: black;
     
    266257    background-color: white;
    267258    vertical-align: top;
    268     font-size: 12pt;
    269   }
    270 
    271   ul.toc a::after {
     259    font-size: 110%;
     260  }
     261
     262  ul.toc a:nth-child(2)::after {
    272263    content: leader('.') target-counter(attr(href), page);
    273264  }
    274  
     265
    275266  ul.ind li li a {
    276267    content: target-counter(attr(href), page);
    277268  }
    278  
     269
    279270  .print2col {
    280271    column-count: 2;
     
    286277@page {
    287278  @top-left {
    288        content: "RFC 2145"; 
    289   } 
     279       content: "RFC 2145";
     280  }
    290281  @top-right {
    291        content: "May 1997"; 
    292   } 
     282       content: "May 1997";
     283  }
    293284  @top-center {
    294        content: "HTTP Version Numbers"; 
    295   } 
     285       content: "HTTP Version Numbers";
     286  }
    296287  @bottom-left {
    297        content: "Mogul, et al."; 
    298   } 
     288       content: "Mogul, et al.";
     289  }
    299290  @bottom-center {
    300        content: "Informational"; 
    301   } 
     291       content: "Informational";
     292  }
    302293  @bottom-right {
    303        content: "[Page " counter(page) "]"; 
    304   } 
    305 }
    306 
    307 @page:first { 
     294       content: "[Page " counter(page) "]";
     295  }
     296}
     297
     298@page:first {
    308299    @top-left {
    309300      content: normal;
     
    326317      <link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc2145">
    327318      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2145">
    328       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.550, 2011-05-30 14:02:12, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     319      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.611, 2013/11/27 12:23:51, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    329320      <meta name="keywords" content="HTTP, hypertext transfer protocol">
    330321      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     
    381372      </table>
    382373      <p class="title">Use and Interpretation of HTTP Version Numbers</p>
    383       <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>
    384       <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
    385          of this memo is unlimited.
    386       </p>
    387       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    388       <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
    389       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
     374      <div id="rfc.status">
     375         <h1><a href="#rfc.status">Status of this Memo</a></h1>
     376         <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
     377            of this memo is unlimited.
     378         </p>
     379      </div>
     380      <div id="rfc.copyrightnotice">
     381         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     382         <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
     383      </div>
     384      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    390385      <p>HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use
    391386         and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol
     
    393388         HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered
    394389         definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP.
    395       </p> 
    396       <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note</a></h1> 
     390      </p>
     391      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note</a></h1>
    397392      <p>Distribution of this document is unlimited. Please send comments to the HTTP working group at &lt;http-wg@cuckoo.hpl.hp.com&gt;.
    398393         Discussions of the working group are archived at &lt;URL:http://www.ics.uci.edu/pub/ietf/http/&gt;. General discussions about HTTP
    399394         and the applications which use HTTP should take place on the &lt;www-talk@w3.org&gt; mailing list.
    400       </p> 
     395      </p>
    401396      <hr class="noprint">
    402397      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    403398      <ul class="toc">
    404          <li>1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul>
    405                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Robustness Principle</a></li>
     399         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul>
     400               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Robustness Principle</a></li>
    406401            </ul>
    407402         </li>
    408          <li>2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP version numbers</a><ul>
    409                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#proxy.behavior">Proxy behavior</a></li>
    410                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Compatibility between minor versions of the same major version</a></li>
    411                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Which version number to send in a message</a></li>
     403         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP version numbers</a><ul>
     404               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#proxy.behavior">Proxy behavior</a></li>
     405               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Compatibility between minor versions of the same major version</a></li>
     406               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Which version number to send in a message</a></li>
    412407            </ul>
    413408         </li>
    414          <li>3.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Security Considerations</a></li>
    415          <li>4.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
    416          <li>5.&nbsp;&nbsp;&nbsp;<a href="#rfc.authors">Authors' Addresses</a></li>
     409         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Security Considerations</a></li>
     410         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
     411         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.authors">Authors' Addresses</a></li>
    417412         <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
    418413      </ul>
    419414      <hr class="noprint">
    420       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    421       </h1>
    422       <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>,
    423       </p>
    424       <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2068#section-3.1">
    425          <p>HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
    426             to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather
    427             than the features obtained via that communication. No change is made to the version number for the addition of message components
    428             which do not affect communication behavior or which only add to extensible field values. The &lt;minor&gt; number is incremented
    429             when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
    430             add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
    431             of a message within the protocol is changed.
    432          </p>
    433       </blockquote>
    434       <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>.
    435       </p>
    436       <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
    437          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
    438          and inconsistency regarding the use and interpretation of HTTP version numbers, and has led to interoperability problems in
    439          certain cases.
    440       </p>
    441       <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
    442          and HTTP/1.1 documents, but it does describe the intention of the authors of those documents. In any case where either of
    443          those two documents is ambiguous regarding the use and interpretation of HTTP version numbers, this document should be considered
    444          the definitive as to the intentions of the designers of HTTP.
    445       </p>
    446       <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
    447          or HTTP/1.1. Rather, this document describes the use of HTTP version numbers in any version of HTTP (except for HTTP/0.9,
    448          which did not include version numbers).
    449       </p>
    450       <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
    451          the implementation conditionally complies with the rules in this document.
    452       </p>
    453       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Robustness Principle
    454       </h2>
    455       <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>:
    456       </p>
    457       <blockquote id="rfc.section.1.1.p.2" cite="http://tools.ietf.org/html/rfc791#section-3.2">
    458          <p>an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.</p>
    459       </blockquote>
    460       <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
    461          might still be ambiguous. In particular, implementations of HTTP <em class="bcp14">SHOULD NOT</em> reject messages or generate errors unnecessarily.
    462       </p>
     415      <div>
     416         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     417         </h1>
     418         <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>,
     419         </p>
     420         <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2068#section-3.1">
     421            <p>HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended
     422               to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather
     423               than the features obtained via that communication. No change is made to the version number for the addition of message components
     424               which do not affect communication behavior or which only add to extensible field values. The &lt;minor&gt; number is incremented
     425               when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
     426               add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
     427               of a message within the protocol is changed.
     428            </p>
     429         </blockquote>
     430         <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>.
     431         </p>
     432         <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
     433            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
     434            and inconsistency regarding the use and interpretation of HTTP version numbers, and has led to interoperability problems in
     435            certain cases.
     436         </p>
     437         <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
     438            and HTTP/1.1 documents, but it does describe the intention of the authors of those documents. In any case where either of
     439            those two documents is ambiguous regarding the use and interpretation of HTTP version numbers, this document should be considered
     440            the definitive as to the intentions of the designers of HTTP.
     441         </p>
     442         <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
     443            or HTTP/1.1. Rather, this document describes the use of HTTP version numbers in any version of HTTP (except for HTTP/0.9,
     444            which did not include version numbers).
     445         </p>
     446         <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
     447            the implementation conditionally complies with the rules in this document.
     448         </p>
     449         <div>
     450            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Robustness Principle
     451            </h2>
     452            <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>:
     453            </p>
     454            <blockquote id="rfc.section.1.1.p.2" cite="http://tools.ietf.org/html/rfc791#section-3.2">
     455               <p>an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.</p>
     456            </blockquote>
     457            <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
     458               might still be ambiguous. In particular, implementations of HTTP <em class="bcp14">SHOULD NOT</em> reject messages or generate errors unnecessarily.
     459            </p>
     460         </div>
     461      </div>
    463462      <hr class="noprint">
    464       <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;HTTP version numbers
    465       </h1>
    466       <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>:
    467       </p>
    468       <ul class="empty">
    469          <li>It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header
    470             does not change between minor versions of the same major version.
    471          </li>
    472          <li>It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header
    473             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.)
    474          </li>
    475       </ul>
    476       <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
    477          of the sender, not the interpretation of the message.
    478       </p>
    479       <div class="note" id="rfc.section.2.p.3">
    480          <p>Note: In a future version of HTTP, we may introduce a mechanism that explicitly requires a receiving implementation to reject
    481             a message if it does not understand certain headers. For example, this might be implemented by means of a header that lists
    482             a set of other message headers that must be understood by the recipient. Any implementation claiming at least conditional
    483             compliance with this future version of HTTP would have to implement this mechanism. However, no implementation claiming compliance
    484             with a lower HTTP version (in particular, HTTP/1.1) will have to implement this mechanism.
    485          </p> 
    486          <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>.
    487          </p>
    488       </div>
    489       <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
    490          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.
    491       </p>
    492       <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>
    493       <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>.
    494       </p>
    495       <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
    496          is, an HTTP proxy never "forwards" an HTTP version number in either a request or response.
    497       </p>
    498       <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
    499       </h2>
    500       <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"
    501          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
    502          is an HTTP/1.1 client.
    503       </p>
    504       <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
    505          cannot be expected to understand chunked encodings, and so an HTTP/1.1 server must never send "Transfer-Encoding: chunked"
    506          in response to an HTTP/1.0 request.
    507       </p>
    508       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Which version number to send in a message
    509       </h2>
    510       <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
    511          follow the robustness principle, and which fail to produce useful results when they receive a message with an HTTP minor version
    512          higher than the minor version they implement. We consider these implementations buggy, but we recognize that the robustness
    513          principle also implies that message senders should make concessions to buggy implementations when this is truly necessary
    514          for interoperation.
    515       </p>
    516       <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
    517          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.
    518       </p>
    519       <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
    520          the client has determined that the server is actually buggy.
    521       </p>
    522       <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
    523          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.
    524       </p>
    525       <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,
    526          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.
    527       </p>
     463      <div>
     464         <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a>&nbsp;HTTP version numbers
     465         </h1>
     466         <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>:
     467         </p>
     468         <ul class="empty">
     469            <li>It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header
     470               does not change between minor versions of the same major version.
     471            </li>
     472            <li>It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header
     473               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.)
     474            </li>
     475         </ul>
     476         <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
     477            of the sender, not the interpretation of the message.
     478         </p>
     479         <div class="note" id="rfc.section.2.p.3">
     480            <p>Note: In a future version of HTTP, we may introduce a mechanism that explicitly requires a receiving implementation to reject
     481               a message if it does not understand certain headers. For example, this might be implemented by means of a header that lists
     482               a set of other message headers that must be understood by the recipient. Any implementation claiming at least conditional
     483               compliance with this future version of HTTP would have to implement this mechanism. However, no implementation claiming compliance
     484               with a lower HTTP version (in particular, HTTP/1.1) will have to implement this mechanism.
     485            </p>
     486            <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>.
     487            </p>
     488         </div>
     489         <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
     490            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.
     491         </p>
     492         <div id="proxy.behavior">
     493            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#proxy.behavior">Proxy behavior</a></h2>
     494            <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>.
     495            </p>
     496            <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
     497               is, an HTTP proxy never "forwards" an HTTP version number in either a request or response.
     498            </p>
     499         </div>
     500         <div>
     501            <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
     502            </h2>
     503            <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"
     504               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
     505               is an HTTP/1.1 client.
     506            </p>
     507            <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
     508               cannot be expected to understand chunked encodings, and so an HTTP/1.1 server must never send "Transfer-Encoding: chunked"
     509               in response to an HTTP/1.0 request.
     510            </p>
     511         </div>
     512         <div>
     513            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Which version number to send in a message
     514            </h2>
     515            <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
     516               follow the robustness principle, and which fail to produce useful results when they receive a message with an HTTP minor version
     517               higher than the minor version they implement. We consider these implementations buggy, but we recognize that the robustness
     518               principle also implies that message senders should make concessions to buggy implementations when this is truly necessary
     519               for interoperation.
     520            </p>
     521            <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
     522               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.
     523            </p>
     524            <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
     525               the client has determined that the server is actually buggy.
     526            </p>
     527            <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
     528               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.
     529            </p>
     530            <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,
     531               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.
     532            </p>
     533         </div>
     534      </div>
    528535      <hr class="noprint">
    529       <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Security Considerations
    530       </h1>
    531       <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
    532          of HTTP version numbers in older implementations.
    533       </p>
     536      <div>
     537         <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a>&nbsp;Security Considerations
     538         </h1>
     539         <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
     540            of HTTP version numbers in older implementations.
     541         </p>
     542      </div>
    534543      <h1 class="np" id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> References
    535544      </h1>
    536       <table> 
     545      <table>
    537546         <tr>
    538547            <td class="reference"><b id="RFC1945">[1]</b></td>
    539548            <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.
    540549            </td>
    541          </tr> 
     550         </tr>
    542551         <tr>
    543552            <td class="reference"><b id="RFC2068">[2]</b></td>
    544553            <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.
    545554            </td>
    546          </tr> 
     555         </tr>
    547556         <tr>
    548557            <td class="reference"><b id="Kha">[3]</b></td>
    549558            <td class="top">Khare, R., “HTTP/1.2 Extension Protocol (PEP)”.<br>HTTP Working Group, Work in Progress.
    550559            </td>
    551          </tr> 
     560         </tr>
    552561         <tr>
    553562            <td class="reference"><b id="RFC0791">[4]</b></td>
    554563            <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc791">Internet Protocol</a>”, RFC&nbsp;791, September&nbsp;1981.
    555564            </td>
    556          </tr> 
     565         </tr>
    557566      </table>
    558567      <hr class="noprint">
    559568      <div class="avoidbreak">
    560569         <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>
    561          <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>
    562          <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>
    563          <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>
    564          <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>
    565       </div>
    566       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    567       <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
    568       <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
    569          explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
    570          restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
    571          works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
    572          to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
    573          in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
    574          translate it into languages other than English.
    575       </p>
    576       <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
    577       <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
    578          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
    579          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
    580          PURPOSE.
    581       </p>
     570         <p><b>Jeffrey C. Mogul</b><br>Western Research Laboratory<br>Digital Equipment Corporation<br>250 University Avenue<br>Palo Alto, California&nbsp;94305<br>USA<br>EMail: <a href="mailto:mogul@wrl.dec.com">mogul@wrl.dec.com</a></p>
     571         <p><b>Roy T. Fielding</b><br>Department of Information and Computer Science<br>University of California<br>Irvine, CA&nbsp;92717-3425<br>USA<br>Fax: <a href="fax:+1(714)824-4056">+1 (714) 824-4056</a><br>EMail: <a href="mailto:fielding@ics.uci.edu">fielding@ics.uci.edu</a></p>
     572         <p><b>Jim Gettys</b><br>MIT Laboratory for Computer Science<br>545 Technology Square<br>Cambridge, MA&nbsp;02139<br>USA<br>Fax: <a href="fax:+1(617)2588682">+1 (617) 258 8682</a><br>EMail: <a href="mailto:jg@w3.org">jg@w3.org</a></p>
     573         <p><b>Henrik Frystyk Nielsen</b><br>W3 Consortium<br>MIT Laboratory for Computer Science<br>545 Technology Square<br>Cambridge, MA&nbsp;02139<br>USA<br>Fax: <a href="fax:+1(617)2588682">+1 (617) 258 8682</a><br>EMail: <a href="mailto:frystyk@w3.org">frystyk@w3.org</a></p>
     574      </div>
     575      <div id="rfc.copyright">
     576         <h1><a href="#rfc.copyright">Full Copyright Statement</a></h1>
     577         <p>Copyright © The Internet Society (1997). All Rights Reserved.</p>
     578         <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
     579            explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
     580            restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
     581            works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
     582            to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
     583            in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
     584            translate it into languages other than English.
     585         </p>
     586         <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
     587         <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
     588            ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
     589            OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
     590            PURPOSE.
     591         </p>
     592      </div>
    582593      <hr class="noprint">
    583       <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    584       <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
    585          to pertain to the implementation or use of the technology described in this document or the extent to which any license under
    586          such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
    587          Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
    588          found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
    589          or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
    590          or users of this specification can be obtained from the IETF Secretariat.
    591       </p>
    592       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    593          rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
    594          Executive Director.
    595       </p>
     594      <div id="rfc.ipr">
     595         <h1 class="np"><a href="#rfc.ipr">Intellectual Property</a></h1>
     596         <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
     597            to pertain to the implementation or use of the technology described in this document or the extent to which any license under
     598            such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
     599            Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
     600            found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
     601            or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
     602            or users of this specification can be obtained from the IETF Secretariat.
     603         </p>
     604         <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
     605            rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
     606            Executive Director.
     607         </p>
     608      </div>
    596609   </body>
    597610</html>
Note: See TracChangeset for help on using the changeset viewer.