Changeset 1148


Ignore:
Timestamp:
05/03/11 10:54:06 (12 years ago)
Author:
fielding@…
Message:

Move section on transport independence up so that it can
describe what connections are before they are used in other
explanations.

Try to explain both the philosophy and practice of HTTP
versioning so that future protocol designers will understand
what the numbers mean and why they are necessary.
Incorporated all of the relevant versioning requirements
from RFC2145 and added that RFC to the obsoleted list.

Addresses #75

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1145 r1148  
    5151<?rfc-ext allow-markup-in-artwork="yes" ?>
    5252<?rfc-ext include-references-in-index="yes" ?>
    53 <rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="draft"
     53<rfc obsoletes="2145,2616" updates="2817" category="std" x:maturity-level="draft"
    5454     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"
    5555     xmlns:x='http://purl.org/net/xml2rfc/ext'>
    … …  
    271271<t>
    272272   This document is Part 1 of the seven-part specification of HTTP,
    273    defining the protocol referred to as "HTTP/1.1" and obsoleting
    274    <xref target="RFC2616"/>.
     273   defining the protocol referred to as "HTTP/1.1", obsoleting
     274   <xref target="RFC2616"/> and <xref target="RFC2145"/>.
    275275   Part 1 describes the architectural elements that are used or
    276276   referred to in HTTP, defines the "http" and "https" URI schemes,
    … …  
    640640</section>
    641641
     642<section title="Connections and Transport Independence" anchor="transport-independence">
     643<t>
     644   HTTP messaging is independent of the underlying transport or
     645   session-layer connection protocol(s).  HTTP only presumes a reliable
     646   transport with in-order delivery of requests and the corresponding
     647   in-order delivery of responses.  The mapping of HTTP request and
     648   response structures onto the data units of the underlying transport
     649   protocol is outside the scope of this specification.
     650</t>
     651<t>
     652   The specific connection protocols to be used for an interaction
     653   are determined by client configuration and the identifier (if any)
     654   provided for the request target.  For example, the "http" URI scheme
     655   (<xref target="http.uri"/>) indicates a default connection of TCP
     656   over IP, with a default TCP port of 80, but the client might be
     657   configured to use a proxy via some other connection port or protocol
     658   instead of using the defaults.
     659</t>
     660<t>
     661   A connection might be used for multiple HTTP request/response exchanges,
     662   as defined in <xref target="persistent.connections"/>.
     663</t>
     664</section>
     665
    642666<section title="Intermediaries" anchor="intermediaries">
    643667<iref primary="true" item="intermediary"/>
    644668<t>
    645    A more complicated situation occurs when one or more intermediaries
    646    are present in the request/response chain. There are three common
    647    forms of intermediary: proxy, gateway, and tunnel.  In some cases,
     669   HTTP enables the use of intermediaries to satisfy requests through
     670   a chain of connections.  There are three common forms of HTTP
     671   intermediary: proxy, gateway, and tunnel.  In some cases,
    648672   a single intermediary might act as an origin server, proxy, gateway,
    649673   or tunnel, switching behavior based on the nature of each request.
    … …  
    790814</section>
    791815
    792 <section title="Transport Independence" anchor="transport-independence">
    793 <t>
    794   HTTP systems are used in a wide variety of environments, from
    795   corporate intranets with high-bandwidth links to long-distance
    796   communication over low-power radio links and intermittent connectivity.
    797 </t>
    798 <t>
    799    HTTP communication usually takes place over TCP/IP connections. The
    800    default port is TCP 80 (<eref target="http://www.iana.org/assignments/port-numbers"/>), but other ports can be used. This does
    801    not preclude HTTP from being implemented on top of any other protocol
    802    on the Internet, or on other networks. HTTP only presumes a reliable
    803    transport; any protocol that provides such guarantees can be used;
    804    the mapping of the HTTP/1.1 request and response structures onto the
    805    transport data units of the protocol in question is outside the scope
    806    of this specification.
    807 </t>
    808 <t>
    809    In HTTP/1.0, most implementations used a new connection for each
    810    request/response exchange. In HTTP/1.1, a connection might be used for
    811    one or more request/response exchanges, although connections might be
    812    closed for a variety of reasons (see <xref target="persistent.connections"/>).
    813 </t>
    814 </section>
    815 
    816 <section title="HTTP Version" anchor="http.version">
     816<section title="Protocol Versioning" anchor="http.version">
    817817  <x:anchor-alias value="HTTP-Version"/>
    818818  <x:anchor-alias value="HTTP-Prot-Name"/>
    819819<t>
    820    HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
    821    of the protocol. The protocol versioning policy is intended to allow
    822    the sender to indicate the format of a message and its capacity for
    823    understanding further HTTP communication, rather than the features
    824    obtained via that communication. No change is made to the version
    825    number for the addition of message components which do not affect
    826    communication behavior or which only add to extensible field values.
    827    The &lt;minor&gt; number is incremented when the changes made to the
    828    protocol add features which do not change the general message parsing
    829    algorithm, but which might add to the message semantics and imply
    830    additional capabilities of the sender. The &lt;major&gt; number is
    831    incremented when the format of a message within the protocol is
    832    changed. See <xref target="RFC2145"/> for a fuller explanation.
     820   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate
     821   versions of the protocol. This specification defines version "1.1".
     822   The protocol version as a whole indicates the sender's compliance
     823   with the set of requirements laid out in that version's corresponding
     824   specification of HTTP.
    833825</t>
    834826<t>
    … …  
    841833</artwork></figure>
    842834<t>
    843    Note that the major and minor numbers &MUST; be treated as separate
    844    integers and that each &MAY; be incremented higher than a single digit.
    845    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
    846    lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
    847    &MUST-NOT; be sent.
    848 </t>
    849 <t>
    850    An application that sends a request or response message that includes
    851    HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
    852    with this specification. Applications that are at least conditionally
    853    compliant with this specification &SHOULD; use an HTTP-Version of
    854    "HTTP/1.1" in their messages, and &MUST; do so for any message that is
    855    not compatible with HTTP/1.0. For more details on when to send
    856    specific HTTP-Version values, see <xref target="RFC2145"/>.
    857 </t>
    858 <t>
    859    The HTTP version of an application is the highest HTTP version for
    860    which the application is at least conditionally compliant.
    861 </t>
    862 <t>
    863    Proxy and gateway applications need to be careful when forwarding
    864    messages in protocol versions different from that of the application.
    865    Since the protocol version indicates the protocol capability of the
    866    sender, a proxy/gateway &MUST-NOT; send a message with a version
    867    indicator which is greater than its actual version. If a higher
    868    version request is received, the proxy/gateway &MUST; either downgrade
    869    the request version, or respond with an error, or switch to tunnel
    870    behavior.
    871 </t>
    872 <t>
    873    Due to interoperability problems with HTTP/1.0 proxies discovered
    874    since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
    875    &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
    876    they support. The proxy/gateway's response to that request &MUST; be in
    877    the same major version as the request.
    878 </t>
    879 <x:note>
    880   <t>
    881     <x:h>Note:</x:h> Converting between versions of HTTP might involve modification
    882     of header fields required or forbidden by the versions involved.
    883   </t>
    884 </x:note>
     835   The HTTP version number consists of two non-negative decimal integers
     836   separated by the "." (period or decimal point) character.  The first
     837   number ("major version") indicates the HTTP messaging syntax, whereas
     838   the second number ("minor version") indicates the highest minor
     839   version to which the sender is at least conditionally compliant and
     840   able to understand for future communication.  The minor version
     841   advertises the sender's communication capabilities even when the
     842   sender is only using a backwards-compatible subset of the protocol,
     843   thereby letting the recipient know that more advanced features can
     844   be used in response (by servers) or in future requests (by clients).
     845</t>
     846<t>
     847   When comparing HTTP versions, the numbers &MUST; be compared
     848   numerically rather than lexically.  For example, HTTP/2.4 is a lower
     849   version than HTTP/2.13, which in turn is lower than HTTP/12.3.
     850   Leading zeros &MUST; be ignored by recipients and &MUST-NOT; be sent.
     851</t>
     852<t>
     853   When an HTTP/1.1 message is sent to an HTTP/1.0 recipient
     854   (or a recipient whose version is unknown), the HTTP/1.1 message is
     855   constructed such that it will be interpreted as a valid HTTP/1.0
     856   message even if all of the provided header fields not defined in
     857   the HTTP/1.0 specification <xref target="RFC1945"/> are ignored.
     858   This specification excludes incompatible message constructions by
     859   imposing recipient-version requirements on new HTTP/1.1 features
     860   that are not safely interpreted by earlier HTTP/1.0 recipients.
     861</t>
     862<t>
     863   The interpretation of an HTTP message header field does not change
     864   between minor versions of the same major version, though the default
     865   behavior of a recipient in the absence of such a field can change.
     866   Unless specified otherwise, header fields defined in HTTP/1.1 are
     867   defined for all versions of HTTP/1.x.  The most popular example of
     868   this is the Host header field, which was introduced during the
     869   standardization process of HTTP/1.1 and widely deployed for HTTP/1.0
     870   requests out of necessity.
     871</t>
     872<t>
     873   Likewise, new header fields can be defined such that, when they are
     874   understood by a recipient, they might override or enhance the
     875   interpretation of previously defined header fields.  When an
     876   implementation receives an unrecognized header field, the recipient
     877   &MUST; ignore that header field for local processing regardless of
     878   the message's HTTP version.  An unrecognized header field received
     879   by a proxy &MUST; be forwarded downstream unless the header field's
     880   field-name is listed in the message's Connection header-field
     881   (see <xref target="header.connection"/>).
     882   These requirements allow HTTP's functionality to be enhanced without
     883   requiring prior update of all compliant intermediaries.
     884</t>
     885<t>
     886   Intermediaries that process HTTP messages (i.e., all intermediaries
     887   other than those acting as a tunnel) &MUST; send their own HTTP-Version
     888   in forwarded messages.  In other words, they &MUST-NOT; blindly
     889   forward the first line of an HTTP message without ensuring that the
     890   protocol version matches what the intermediary understands, and
     891   is at least conditionally compliant to, for both the receiving and
     892   sending of messages.  Forwarding an HTTP message without rewriting
     893   the HTTP-Version might result in communication errors when downstream
     894   recipients use the message sender's version to determine what features
     895   are safe to use for later communication with that sender.
     896</t>
     897<t>
     898   An HTTP client &SHOULD; send a request version equal to the highest
     899   version for which the client is at least conditionally compliant and
     900   whose major version is no higher than the highest version supported
     901   by the server, if this is known.  An HTTP client &MUST-NOT; send a
     902   version for which it is not at least conditionally compliant.
     903</t>
     904<t>
     905   An HTTP client &MAY; send a lower request version if it is known that
     906   the server incorrectly implements the HTTP specification, but only
     907   after the client has attempted at least one normal request and determined
     908   from the response status or header fields (e.g., Server) that the
     909   server improperly handles higher request versions.
     910</t>
     911<t>
     912   An HTTP server &SHOULD; send a response version equal to the highest
     913   version for which the server is at least conditionally compliant and
     914   whose major version is less than or equal to the one received in the
     915   request.  An HTTP server &MUST-NOT; send a version for which it is not
     916   at least conditionally compliant.  A server &MAY; send a 505 (HTTP
     917   Version Not Supported) response if it cannot send a response using the
     918   major version used in the client's request.
     919</t>
     920<t>
     921   An HTTP server &MAY; send an HTTP/1.0 response to an HTTP/1.0 request
     922   if it is known or suspected that the client incorrectly implements the
     923   HTTP specification and is incapable of correctly processing later
     924   version responses, such as when a client fails to parse the version
     925   number correctly or when an intermediary is known to blindly forward
     926   the HTTP-Version even when it doesn't comply with the given minor
     927   version of the protocol. Such protocol downgrades &SHOULD-NOT; be
     928   performed unless triggered by specific client attributes, such as when
     929   one or more of the request header fields (e.g., User-Agent) uniquely
     930   match the values sent by a client known to be in error.
     931</t>
     932<t>
     933   The intention of HTTP's versioning design is that the major number
     934   will only be incremented if an incompatible message syntax is
     935   introduced, and that the minor number will only be incremented when
     936   changes made to the protocol have the effect of adding to the message
     937   semantics or implying additional capabilities of the sender.  However,
     938   the minor version was not incremented for the changes introduced in
     939   <xref target="RFC2616"/>, and this revision is specifically avoiding
     940   any such changes to the protocol.
     941</t>
    885942</section>
    886943
Note: See TracChangeset for help on using the changeset viewer.