Ignore:
Timestamp:
Jul 26, 2009, 5:11:17 AM (10 years ago)
Author:
fielding@…
Message:

Move the section on HTTP Version after the section on overall operation
because it reflects an architecture issue and fits well here due to
the constraints on forwarding. No content is changed.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r624 r625  
    617617</section>
    618618
     619<section title="HTTP Version" anchor="http.version">
     620  <x:anchor-alias value="HTTP-Version"/>
     621  <x:anchor-alias value="HTTP-Prot-Name"/>
     622<t>
     623   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
     624   of the protocol. The protocol versioning policy is intended to allow
     625   the sender to indicate the format of a message and its capacity for
     626   understanding further HTTP communication, rather than the features
     627   obtained via that communication. No change is made to the version
     628   number for the addition of message components which do not affect
     629   communication behavior or which only add to extensible field values.
     630   The &lt;minor&gt; number is incremented when the changes made to the
     631   protocol add features which do not change the general message parsing
     632   algorithm, but which may add to the message semantics and imply
     633   additional capabilities of the sender. The &lt;major&gt; number is
     634   incremented when the format of a message within the protocol is
     635   changed. See <xref target="RFC2145"/> for a fuller explanation.
     636</t>
     637<t>
     638   The version of an HTTP message is indicated by an HTTP-Version field
     639   in the first line of the message. HTTP-Version is case-sensitive.
     640</t>
     641<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>
     642  <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
     643  <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
     644</artwork></figure>
     645<t>
     646   Note that the major and minor numbers &MUST; be treated as separate
     647   integers and that each &MAY; be incremented higher than a single digit.
     648   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
     649   lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
     650   &MUST-NOT; be sent.
     651</t>
     652<t>
     653   An application that sends a request or response message that includes
     654   HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
     655   with this specification. Applications that are at least conditionally
     656   compliant with this specification &SHOULD; use an HTTP-Version of
     657   "HTTP/1.1" in their messages, and &MUST; do so for any message that is
     658   not compatible with HTTP/1.0. For more details on when to send
     659   specific HTTP-Version values, see <xref target="RFC2145"/>.
     660</t>
     661<t>
     662   The HTTP version of an application is the highest HTTP version for
     663   which the application is at least conditionally compliant.
     664</t>
     665<t>
     666   Proxy and gateway applications need to be careful when forwarding
     667   messages in protocol versions different from that of the application.
     668   Since the protocol version indicates the protocol capability of the
     669   sender, a proxy/gateway &MUST-NOT; send a message with a version
     670   indicator which is greater than its actual version. If a higher
     671   version request is received, the proxy/gateway &MUST; either downgrade
     672   the request version, or respond with an error, or switch to tunnel
     673   behavior.
     674</t>
     675<t>
     676   Due to interoperability problems with HTTP/1.0 proxies discovered
     677   since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
     678   &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
     679   they support. The proxy/gateway's response to that request &MUST; be in
     680   the same major version as the request.
     681</t>
     682<x:note>
     683  <t>
     684    <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
     685    of header fields required or forbidden by the versions involved.
     686  </t>
     687</x:note>
     688</section>
     689
    619690<section title="Uniform Resource Identifiers" anchor="uri">
    620691<iref primary="true" item="resource"/>
    … …  
    14211492
    14221493<section title="Protocol Parameters" anchor="protocol.parameters">
    1423 
    1424 <section title="HTTP Version" anchor="http.version">
    1425   <x:anchor-alias value="HTTP-Version"/>
    1426   <x:anchor-alias value="HTTP-Prot-Name"/>
    1427 <t>
    1428    HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
    1429    of the protocol. The protocol versioning policy is intended to allow
    1430    the sender to indicate the format of a message and its capacity for
    1431    understanding further HTTP communication, rather than the features
    1432    obtained via that communication. No change is made to the version
    1433    number for the addition of message components which do not affect
    1434    communication behavior or which only add to extensible field values.
    1435    The &lt;minor&gt; number is incremented when the changes made to the
    1436    protocol add features which do not change the general message parsing
    1437    algorithm, but which may add to the message semantics and imply
    1438    additional capabilities of the sender. The &lt;major&gt; number is
    1439    incremented when the format of a message within the protocol is
    1440    changed. See <xref target="RFC2145"/> for a fuller explanation.
    1441 </t>
    1442 <t>
    1443    The version of an HTTP message is indicated by an HTTP-Version field
    1444    in the first line of the message. HTTP-Version is case-sensitive.
    1445 </t>
    1446 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>
    1447   <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
    1448   <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
    1449 </artwork></figure>
    1450 <t>
    1451    Note that the major and minor numbers &MUST; be treated as separate
    1452    integers and that each &MAY; be incremented higher than a single digit.
    1453    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
    1454    lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
    1455    &MUST-NOT; be sent.
    1456 </t>
    1457 <t>
    1458    An application that sends a request or response message that includes
    1459    HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
    1460    with this specification. Applications that are at least conditionally
    1461    compliant with this specification &SHOULD; use an HTTP-Version of
    1462    "HTTP/1.1" in their messages, and &MUST; do so for any message that is
    1463    not compatible with HTTP/1.0. For more details on when to send
    1464    specific HTTP-Version values, see <xref target="RFC2145"/>.
    1465 </t>
    1466 <t>
    1467    The HTTP version of an application is the highest HTTP version for
    1468    which the application is at least conditionally compliant.
    1469 </t>
    1470 <t>
    1471    Proxy and gateway applications need to be careful when forwarding
    1472    messages in protocol versions different from that of the application.
    1473    Since the protocol version indicates the protocol capability of the
    1474    sender, a proxy/gateway &MUST-NOT; send a message with a version
    1475    indicator which is greater than its actual version. If a higher
    1476    version request is received, the proxy/gateway &MUST; either downgrade
    1477    the request version, or respond with an error, or switch to tunnel
    1478    behavior.
    1479 </t>
    1480 <t>
    1481    Due to interoperability problems with HTTP/1.0 proxies discovered
    1482    since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
    1483    &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
    1484    they support. The proxy/gateway's response to that request &MUST; be in
    1485    the same major version as the request.
    1486 </t>
    1487 <x:note>
    1488   <t>
    1489     <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
    1490     of header fields required or forbidden by the versions involved.
    1491   </t>
    1492 </x:note>
    1493 </section>
    14941494
    14951495<section title="Date/Time Formats: Full Date" anchor="date.time.formats.full.date">
Note: See TracChangeset for help on using the changeset viewer.