Ignore:
Timestamp:
Mar 11, 2012, 8:57:38 PM (7 years ago)
Author:
fielding@…
Message:

Split connections into forwarding of messages by intermediaries and
connection management (relocations and minor wording additions only).
Move definition of Connection, Via, and Upgrade into connection management.
Related to #284.

Remove miscellaneous notes and now-empty header field section.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1582 r1583  
    426426   protocol version (<xref target="request.line"/>),
    427427   followed by MIME-like header fields containing
    428    request modifiers, client information, and payload metadata
     428   request modifiers, client information, and representation metadata
    429429   (<xref target="header.fields"/>),
    430430   an empty line to indicate the end of the header section, and finally
     
    439439   reason phrase (<xref target="status.line"/>),
    440440   possibly followed by MIME-like header fields containing server
    441    information, resource metadata, and payload metadata
     441   information, resource metadata, and representation metadata
    442442   (<xref target="header.fields"/>),
    443443   an empty line to indicate the end of the header section, and finally
     
    23552355<section title="Request Target" anchor="request-target">
    23562356<t>
    2357    Once an inbound connection is obtained (<xref target="connections"/>),
     2357   Once an inbound connection is obtained
     2358   (<xref target="connection.management"/>),
    23582359   the client sends an HTTP request message (<xref target="http.message"/>)
    23592360   with a request-target derived from the target URI.
     
    24092410   if possible, or make the same request on the client's behalf to either
    24102411   the next inbound proxy server or directly to the origin server indicated
    2411    by the request-target.
    2412    In order to avoid request loops, a proxy that forwards requests to other
    2413    proxies &MUST; be able to recognize and exclude all of its own server
    2414    names, including any aliases, local variations, or literal IP addresses.
     2412   by the request-target.  Requirements on such "forwarding" of messages are
     2413   defined in <xref target="intermediary.forwarding"/>.
    24152414</t>
    24162415<t>
     
    24672466</postamble>
    24682467</figure>
    2469 <t>
    2470    If a proxy receives a request-target with a host name that is not a
    2471    fully qualified domain name, it &MAY; add its domain to the host name
    2472    it received when forwarding the request.  A proxy &MUST-NOT; change the
    2473    host name if it is a fully qualified domain name.
    2474 </t>
    2475 <t>
    2476    A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    2477    parts of the received request-target when forwarding it to the next inbound
    2478    server, except as noted above to replace an empty path with "/" or "*".
    2479 </t>
    24802468</section>
    24812469
     
    26312619</section>
    26322620
     2621<section title="Intermediary Forwarding" anchor="intermediary.forwarding">
     2622<t>
     2623   As described in <xref target="intermediaries"/>, intermediaries can serve
     2624   a variety of roles in the processing of HTTP requests and responses.
     2625   Some intermediaries are used to improve performance or availability.
     2626   Others are used for access control or to filter content.
     2627   Since an HTTP stream has characteristics similar to a pipe-and-filter
     2628   architecture, there are no inherent limits to the extent an intermediary
     2629   can enhance (or interfere) with either direction of the stream.
     2630</t>
     2631<t>
     2632   In order to avoid request loops, a proxy that forwards requests to other
     2633   proxies &MUST; be able to recognize and exclude all of its own server
     2634   names, including any aliases, local variations, or literal IP addresses.
     2635</t>
     2636<t>
     2637   If a proxy receives a request-target with a host name that is not a
     2638   fully qualified domain name, it &MAY; add its domain to the host name
     2639   it received when forwarding the request.  A proxy &MUST-NOT; change the
     2640   host name if it is a fully qualified domain name.
     2641</t>
     2642<t>
     2643   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
     2644   parts of the received request-target when forwarding it to the next inbound
     2645   server, except as noted above to replace an empty path with "/" or "*".
     2646</t>
     2647<t>
     2648   Intermediaries that forward a message &MUST; implement the
     2649   Connection header field as specified in <xref target="header.connection"/>.
     2650</t>
     2651
     2652<section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
     2653<!--<t>
     2654  <cref anchor="TODO-end-to-end" source="jre">
     2655    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>.
     2656    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
     2657  </cref>
     2658</t>-->
     2659<t>
     2660   For the purpose of defining the behavior of caches and non-caching
     2661   proxies, we divide HTTP header fields into two categories:
     2662  <list style="symbols">
     2663      <t>End-to-end header fields, which are  transmitted to the ultimate
     2664        recipient of a request or response. End-to-end header fields in
     2665        responses &MUST; be stored as part of a cache entry and &MUST; be
     2666        transmitted in any response formed from a cache entry.</t>
     2667
     2668      <t>Hop-by-hop header fields, which are meaningful only for a single
     2669        transport-level connection, and are not stored by caches or
     2670        forwarded by proxies.</t>
     2671  </list>
     2672</t>
     2673<t>
     2674   The following HTTP/1.1 header fields are hop-by-hop header fields:
     2675  <list style="symbols">
     2676      <t>Connection</t>
     2677      <t>Keep-Alive</t>
     2678      <t>Proxy-Authenticate</t>
     2679      <t>Proxy-Authorization</t>
     2680      <t>TE</t>
     2681      <t>Trailer</t>
     2682      <t>Transfer-Encoding</t>
     2683      <t>Upgrade</t>
     2684  </list>
     2685</t>
     2686<t>
     2687   All other header fields defined by HTTP/1.1 are end-to-end header fields.
     2688</t>
     2689<t>
     2690   Other hop-by-hop header fields &MUST; be listed in a Connection header field
     2691   (<xref target="header.connection"/>).
     2692</t>
     2693</section>
     2694
     2695<section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
     2696<!--<t>
     2697  <cref anchor="TODO-non-mod-headers" source="jre">
     2698    Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>.
     2699    See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
     2700  </cref>
     2701</t>-->
     2702<t>
     2703   Some features of HTTP/1.1, such as Digest Authentication, depend on the
     2704   value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
     2705   modify an end-to-end header field unless the definition of that header field requires
     2706   or specifically allows that.
     2707</t>
     2708<t>
     2709   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
     2710   request or response, and it &MUST-NOT; add any of these fields if not
     2711   already present:
     2712  <list style="symbols">
     2713    <t>Allow</t>
     2714    <t>Content-Location</t>
     2715    <t>Content-MD5</t>
     2716    <t>ETag</t>
     2717    <t>Last-Modified</t>
     2718    <t>Server</t>
     2719  </list>
     2720</t>
     2721<t>
     2722   A non-transforming proxy &MUST-NOT; modify any of the following fields in a
     2723   response:
     2724  <list style="symbols">
     2725    <t>Expires</t>
     2726  </list>
     2727</t>
     2728<t>
     2729   but it &MAY; add any of these fields if not already present. If an
     2730   Expires header field is added, it &MUST; be given a field-value identical to
     2731   that of the Date header field in that response.
     2732</t>
     2733<t>
     2734   A proxy &MUST-NOT; modify or add any of the following fields in a
     2735   message that contains the no-transform cache-control directive, or in
     2736   any request:
     2737  <list style="symbols">
     2738    <t>Content-Encoding</t>
     2739    <t>Content-Range</t>
     2740    <t>Content-Type</t>
     2741  </list>
     2742</t>
     2743<t>
     2744   A transforming proxy &MAY; modify or add these fields to a message
     2745   that does not include no-transform, but if it does so, it &MUST; add a
     2746   Warning 214 (Transformation applied) if one does not already appear
     2747   in the message (see &header-warning;).
     2748</t>
     2749<x:note>
     2750  <t>
     2751    <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
     2752    cause authentication failures if stronger authentication
     2753    mechanisms are introduced in later versions of HTTP. Such
     2754    authentication mechanisms &MAY; rely on the values of header fields
     2755    not listed here.
     2756  </t>
     2757</x:note>
     2758<t>
     2759   A non-transforming proxy &MUST; preserve the message payload (&payload;),
     2760   though it &MAY; change the message body through application or removal
     2761   of a transfer-coding (<xref target="transfer.codings"/>).
     2762</t>
     2763</section>
     2764
     2765</section>
     2766
    26332767<section title="Associating a Response to a Request" anchor="associating.response.to.request">
    26342768<t>
     
    26512785</section>
    26522786
    2653 <section title="Connections" anchor="connections">
     2787<section title="Connection Management" anchor="connection.management">
     2788
     2789<section title="Connection" anchor="header.connection">
     2790  <iref primary="true" item="Connection header field" x:for-anchor=""/>
     2791  <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/>
     2792  <x:anchor-alias value="Connection"/>
     2793  <x:anchor-alias value="connection-token"/>
     2794<t>
     2795   The "Connection" header field allows the sender to specify
     2796   options that are desired only for that particular connection.
     2797   Such connection options &MUST; be removed or replaced before the
     2798   message can be forwarded downstream by a proxy or gateway.
     2799   This mechanism also allows the sender to indicate which HTTP
     2800   header fields used in the message are only intended for the
     2801   immediate recipient ("hop-by-hop"), as opposed to all recipients
     2802   on the chain ("end-to-end"), enabling the message to be
     2803   self-descriptive and allowing future connection-specific extensions
     2804   to be deployed in HTTP without fear that they will be blindly
     2805   forwarded by previously deployed intermediaries.
     2806</t>
     2807<t>
     2808   The Connection header field's value has the following grammar:
     2809</t>
     2810<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/>
     2811  <x:ref>Connection</x:ref>       = 1#<x:ref>connection-token</x:ref>
     2812  <x:ref>connection-token</x:ref> = <x:ref>token</x:ref>
     2813</artwork></figure>
     2814<t>
     2815   A proxy or gateway &MUST; parse a received Connection
     2816   header field before a message is forwarded and, for each
     2817   connection-token in this field, remove any header field(s) from
     2818   the message with the same name as the connection-token, and then
     2819   remove the Connection header field itself or replace it with the
     2820   sender's own connection options for the forwarded message.
     2821</t>
     2822<t>
     2823   A sender &MUST-NOT; include field-names in the Connection header
     2824   field-value for fields that are defined as expressing constraints
     2825   for all recipients in the request or response chain, such as the
     2826   Cache-Control header field (&header-cache-control;).
     2827</t>
     2828<t>
     2829   The connection options do not have to correspond to a header field
     2830   present in the message, since a connection-specific header field
     2831   might not be needed if there are no parameters associated with that
     2832   connection option.  Recipients that trigger certain connection
     2833   behavior based on the presence of connection options &MUST; do so
     2834   based on the presence of the connection-token rather than only the
     2835   presence of the optional header field.  In other words, if the
     2836   connection option is received as a header field but not indicated
     2837   within the Connection field-value, then the recipient &MUST; ignore
     2838   the connection-specific header field because it has likely been
     2839   forwarded by an intermediary that is only partially conformant.
     2840</t>
     2841<t>
     2842   When defining new connection options, specifications ought to
     2843   carefully consider existing deployed header fields and ensure
     2844   that the new connection-token does not share the same name as
     2845   an unrelated header field that might already be deployed.
     2846   Defining a new connection-token essentially reserves that potential
     2847   field-name for carrying additional information related to the
     2848   connection option, since it would be unwise for senders to use
     2849   that field-name for anything else.
     2850</t>
     2851<t>
     2852   HTTP/1.1 defines the "close" connection option for the sender to
     2853   signal that the connection will be closed after completion of the
     2854   response. For example,
     2855</t>
     2856<figure><artwork type="example">
     2857  Connection: close
     2858</artwork></figure>
     2859<t>
     2860   in either the request or the response header fields indicates that
     2861   the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
     2862   after the current request/response is complete.
     2863</t>
     2864<t>
     2865   An HTTP/1.1 client that does not support persistent connections &MUST;
     2866   include the "close" connection option in every request message.
     2867</t>
     2868<t>
     2869   An HTTP/1.1 server that does not support persistent connections &MUST;
     2870   include the "close" connection option in every response message that
     2871   does not have a 1xx (Informational) status code.
     2872</t>
     2873</section>
     2874
     2875<section title="Via" anchor="header.via">
     2876  <iref primary="true" item="Via header field" x:for-anchor=""/>
     2877  <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
     2878  <x:anchor-alias value="pseudonym"/>
     2879  <x:anchor-alias value="received-by"/>
     2880  <x:anchor-alias value="received-protocol"/>
     2881  <x:anchor-alias value="Via"/>
     2882<t>
     2883   The "Via" header field &MUST; be sent by a proxy or gateway to
     2884   indicate the intermediate protocols and recipients between the user
     2885   agent and the server on requests, and between the origin server and
     2886   the client on responses. It is analogous to the "Received" field
     2887   used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
     2888   and is intended to be used for tracking message forwards,
     2889   avoiding request loops, and identifying the protocol capabilities of
     2890   all senders along the request/response chain.
     2891</t>
     2892<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
     2893  <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
     2894                          [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
     2895  <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
     2896  <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
     2897  <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
     2898</artwork></figure>
     2899<t>
     2900   The received-protocol indicates the protocol version of the message
     2901   received by the server or client along each segment of the
     2902   request/response chain. The received-protocol version is appended to
     2903   the Via field value when the message is forwarded so that information
     2904   about the protocol capabilities of upstream applications remains
     2905   visible to all recipients.
     2906</t>
     2907<t>
     2908   The protocol-name is excluded if and only if it would be "HTTP". The
     2909   received-by field is normally the host and optional port number of a
     2910   recipient server or client that subsequently forwarded the message.
     2911   However, if the real host is considered to be sensitive information,
     2912   it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
     2913   be assumed to be the default port of the received-protocol.
     2914</t>
     2915<t>
     2916   Multiple Via field values represent each proxy or gateway that has
     2917   forwarded the message. Each recipient &MUST; append its information
     2918   such that the end result is ordered according to the sequence of
     2919   forwarding applications.
     2920</t>
     2921<t>
     2922   Comments &MAY; be used in the Via header field to identify the software
     2923   of each recipient, analogous to the User-Agent and Server header fields.
     2924   However, all comments in the Via field are optional and &MAY; be removed
     2925   by any recipient prior to forwarding the message.
     2926</t>
     2927<t>
     2928   For example, a request message could be sent from an HTTP/1.0 user
     2929   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
     2930   forward the request to a public proxy at p.example.net, which completes
     2931   the request by forwarding it to the origin server at www.example.com.
     2932   The request received by www.example.com would then have the following
     2933   Via header field:
     2934</t>
     2935<figure><artwork type="example">
     2936  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
     2937</artwork></figure>
     2938<t>
     2939   A proxy or gateway used as a portal through a network firewall
     2940   &SHOULD-NOT; forward the names and ports of hosts within the firewall
     2941   region unless it is explicitly enabled to do so. If not enabled, the
     2942   received-by host of any host behind the firewall &SHOULD; be replaced
     2943   by an appropriate pseudonym for that host.
     2944</t>
     2945<t>
     2946   For organizations that have strong privacy requirements for hiding
     2947   internal structures, a proxy or gateway &MAY; combine an ordered
     2948   subsequence of Via header field entries with identical received-protocol
     2949   values into a single such entry. For example,
     2950</t>
     2951<figure><artwork type="example">
     2952  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     2953</artwork></figure>
     2954<t>
     2955  could be collapsed to
     2956</t>
     2957<figure><artwork type="example">
     2958  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     2959</artwork></figure>
     2960<t>
     2961   Senders &SHOULD-NOT; combine multiple entries unless they are all
     2962   under the same organizational control and the hosts have already been
     2963   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
     2964   have different received-protocol values.
     2965</t>
     2966</section>
    26542967
    26552968<section title="Persistent Connections" anchor="persistent.connections">
     
    27513064</t>
    27523065<t>
     3066   Each persistent connection applies to only one transport link.
     3067</t>
     3068<t>
     3069   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
     3070   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
     3071   for information and discussion of the problems with the Keep-Alive header field
     3072   implemented by many HTTP/1.0 clients).
     3073</t>
     3074<t>
    27533075   In order to remain persistent, all messages on the connection &MUST;
    27543076   have a self-defined message length (i.e., one not defined by closure
     
    27823104</t>
    27833105</section>
    2784 </section>
    2785 
    2786 <section title="Proxy Servers" anchor="persistent.proxy">
    2787 <t>
    2788    It is especially important that proxies correctly implement the
    2789    properties of the Connection header field as specified in <xref target="header.connection"/>.
    2790 </t>
    2791 <t>
    2792    The proxy server &MUST; signal persistent connections separately with
    2793    its clients and the origin servers (or other proxy servers) that it
    2794    connects to. Each persistent connection applies to only one transport
    2795    link.
    2796 </t>
    2797 <t>
    2798    A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    2799    with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
    2800    for information and discussion of the problems with the Keep-Alive header field
    2801    implemented by many HTTP/1.0 clients).
    2802 </t>
    2803 
    2804 <section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
    2805 <!--<t>
    2806   <cref anchor="TODO-end-to-end" source="jre">
    2807     Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.1"/>.
    2808     See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
    2809   </cref>
    2810 </t>-->
    2811 <t>
    2812    For the purpose of defining the behavior of caches and non-caching
    2813    proxies, we divide HTTP header fields into two categories:
    2814   <list style="symbols">
    2815       <t>End-to-end header fields, which are  transmitted to the ultimate
    2816         recipient of a request or response. End-to-end header fields in
    2817         responses &MUST; be stored as part of a cache entry and &MUST; be
    2818         transmitted in any response formed from a cache entry.</t>
    2819 
    2820       <t>Hop-by-hop header fields, which are meaningful only for a single
    2821         transport-level connection, and are not stored by caches or
    2822         forwarded by proxies.</t>
    2823   </list>
    2824 </t>
    2825 <t>
    2826    The following HTTP/1.1 header fields are hop-by-hop header fields:
    2827   <list style="symbols">
    2828       <t>Connection</t>
    2829       <t>Keep-Alive</t>
    2830       <t>Proxy-Authenticate</t>
    2831       <t>Proxy-Authorization</t>
    2832       <t>TE</t>
    2833       <t>Trailer</t>
    2834       <t>Transfer-Encoding</t>
    2835       <t>Upgrade</t>
    2836   </list>
    2837 </t>
    2838 <t>
    2839    All other header fields defined by HTTP/1.1 are end-to-end header fields.
    2840 </t>
    2841 <t>
    2842    Other hop-by-hop header fields &MUST; be listed in a Connection header field
    2843    (<xref target="header.connection"/>).
    2844 </t>
    2845 </section>
    2846 
    2847 <section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
    2848 <!--<t>
    2849   <cref anchor="TODO-non-mod-headers" source="jre">
    2850     Restored from <eref target="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-05#section-7.2"/>.
    2851     See also <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/60"/>.
    2852   </cref>
    2853 </t>-->
    2854 <t>
    2855    Some features of HTTP/1.1, such as Digest Authentication, depend on the
    2856    value of certain end-to-end header fields. A non-transforming proxy &SHOULD-NOT;
    2857    modify an end-to-end header field unless the definition of that header field requires
    2858    or specifically allows that.
    2859 </t>
    2860 <t>
    2861    A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    2862    request or response, and it &MUST-NOT; add any of these fields if not
    2863    already present:
    2864   <list style="symbols">
    2865     <t>Allow</t>
    2866     <t>Content-Location</t>
    2867     <t>Content-MD5</t>
    2868     <t>ETag</t>
    2869     <t>Last-Modified</t>
    2870     <t>Server</t>
    2871   </list>
    2872 </t>
    2873 <t>
    2874    A non-transforming proxy &MUST-NOT; modify any of the following fields in a
    2875    response:
    2876   <list style="symbols">
    2877     <t>Expires</t>
    2878   </list>
    2879 </t>
    2880 <t>
    2881    but it &MAY; add any of these fields if not already present. If an
    2882    Expires header field is added, it &MUST; be given a field-value identical to
    2883    that of the Date header field in that response.
    2884 </t>
    2885 <t>
    2886    A proxy &MUST-NOT; modify or add any of the following fields in a
    2887    message that contains the no-transform cache-control directive, or in
    2888    any request:
    2889   <list style="symbols">
    2890     <t>Content-Encoding</t>
    2891     <t>Content-Range</t>
    2892     <t>Content-Type</t>
    2893   </list>
    2894 </t>
    2895 <t>
    2896    A transforming proxy &MAY; modify or add these fields to a message
    2897    that does not include no-transform, but if it does so, it &MUST; add a
    2898    Warning 214 (Transformation applied) if one does not already appear
    2899    in the message (see &header-warning;).
    2900 </t>
    2901 <x:note>
    2902   <t>
    2903     <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
    2904     cause authentication failures if stronger authentication
    2905     mechanisms are introduced in later versions of HTTP. Such
    2906     authentication mechanisms &MAY; rely on the values of header fields
    2907     not listed here.
    2908   </t>
    2909 </x:note>
    2910 <t>
    2911    A non-transforming proxy &MUST; preserve the message payload (&payload;),
    2912    though it &MAY; change the message body through application or removal
    2913    of a transfer-coding (<xref target="transfer.codings"/>).
    2914 </t>
    2915 </section>
    2916 
    29173106</section>
    29183107
     
    29823171</t>
    29833172</section>
    2984 
    29853173</section>
    29863174
     
    31323320</section>
    31333321
    3134 </section>
    3135 </section>
    3136 
    3137 
    3138 <section title="Miscellaneous notes that might disappear" anchor="misc">
    3139 <section title="Scheme aliases considered harmful" anchor="scheme.aliases">
    3140 <t>
    3141    <cref anchor="TBD-aliases-harmful">describe why aliases like webcal are harmful.</cref>
    3142 </t>
    3143 </section>
    3144 
    3145 <section title="Use of HTTP for proxy communication" anchor="http.proxy">
    3146 <t>
    3147    <cref anchor="TBD-proxy-other">Configured to use HTTP to proxy HTTP or other protocols.</cref>
    3148 </t>
    3149 </section>
    3150 
    3151 <section title="Interception of HTTP for access control" anchor="http.intercept">
    3152 <t>
    3153    <cref anchor="TBD-intercept">Interception of HTTP traffic for initiating access control.</cref>
    3154 </t>
    3155 </section>
    3156 
    3157 <section title="Use of HTTP by other protocols" anchor="http.others">
    3158 <t>
    3159    <cref anchor="TBD-profiles">Profiles of HTTP defined by other protocol.
    3160    Extensions of HTTP like WebDAV.</cref>
    3161 </t>
    3162 
    3163 </section>
    3164 <section title="Use of HTTP by media type specification" anchor="http.media">
    3165 <t>
    3166    <cref anchor="TBD-hypertext">Instructions on composing HTTP requests via hypertext formats.</cref>
    3167 </t>
    3168 </section>
    3169 </section>
    3170 
    3171 <section title="Header Field Definitions" anchor="header.field.definitions">
    3172 <t>
    3173    This section defines the syntax and semantics of HTTP header fields
    3174    related to message origination, framing, and routing.
    3175 </t>
    3176 <texttable align="left">
    3177   <ttcol>Header Field Name</ttcol>
    3178   <ttcol>Defined in...</ttcol>
    3179  
    3180   <c>Connection</c> <c><xref target="header.connection"/></c>
    3181   <c>Content-Length</c> <c><xref target="header.content-length"/></c>
    3182   <c>Host</c> <c><xref target="header.host"/></c>
    3183   <c>TE</c> <c><xref target="header.te"/></c>
    3184   <c>Trailer</c> <c><xref target="header.trailer"/></c>
    3185   <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
    3186   <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
    3187   <c>Via</c> <c><xref target="header.via"/></c>
    3188 </texttable>
    3189 
    3190 <section title="Connection" anchor="header.connection">
    3191   <iref primary="true" item="Connection header field" x:for-anchor=""/>
    3192   <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/>
    3193   <x:anchor-alias value="Connection"/>
    3194   <x:anchor-alias value="connection-token"/>
    3195 <t>
    3196    The "Connection" header field allows the sender to specify
    3197    options that are desired only for that particular connection.
    3198    Such connection options &MUST; be removed or replaced before the
    3199    message can be forwarded downstream by a proxy or gateway.
    3200    This mechanism also allows the sender to indicate which HTTP
    3201    header fields used in the message are only intended for the
    3202    immediate recipient ("hop-by-hop"), as opposed to all recipients
    3203    on the chain ("end-to-end"), enabling the message to be
    3204    self-descriptive and allowing future connection-specific extensions
    3205    to be deployed in HTTP without fear that they will be blindly
    3206    forwarded by previously deployed intermediaries.
    3207 </t>
    3208 <t>
    3209    The Connection header field's value has the following grammar:
    3210 </t>
    3211 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/>
    3212   <x:ref>Connection</x:ref>       = 1#<x:ref>connection-token</x:ref>
    3213   <x:ref>connection-token</x:ref> = <x:ref>token</x:ref>
    3214 </artwork></figure>
    3215 <t>
    3216    A proxy or gateway &MUST; parse a received Connection
    3217    header field before a message is forwarded and, for each
    3218    connection-token in this field, remove any header field(s) from
    3219    the message with the same name as the connection-token, and then
    3220    remove the Connection header field itself or replace it with the
    3221    sender's own connection options for the forwarded message.
    3222 </t>
    3223 <t>
    3224    A sender &MUST-NOT; include field-names in the Connection header
    3225    field-value for fields that are defined as expressing constraints
    3226    for all recipients in the request or response chain, such as the
    3227    Cache-Control header field (&header-cache-control;).
    3228 </t>
    3229 <t>
    3230    The connection options do not have to correspond to a header field
    3231    present in the message, since a connection-specific header field
    3232    might not be needed if there are no parameters associated with that
    3233    connection option.  Recipients that trigger certain connection
    3234    behavior based on the presence of connection options &MUST; do so
    3235    based on the presence of the connection-token rather than only the
    3236    presence of the optional header field.  In other words, if the
    3237    connection option is received as a header field but not indicated
    3238    within the Connection field-value, then the recipient &MUST; ignore
    3239    the connection-specific header field because it has likely been
    3240    forwarded by an intermediary that is only partially conformant.
    3241 </t>
    3242 <t>
    3243    When defining new connection options, specifications ought to
    3244    carefully consider existing deployed header fields and ensure
    3245    that the new connection-token does not share the same name as
    3246    an unrelated header field that might already be deployed.
    3247    Defining a new connection-token essentially reserves that potential
    3248    field-name for carrying additional information related to the
    3249    connection option, since it would be unwise for senders to use
    3250    that field-name for anything else.
    3251 </t>
    3252 <t>
    3253    HTTP/1.1 defines the "close" connection option for the sender to
    3254    signal that the connection will be closed after completion of the
    3255    response. For example,
    3256 </t>
    3257 <figure><artwork type="example">
    3258   Connection: close
    3259 </artwork></figure>
    3260 <t>
    3261    in either the request or the response header fields indicates that
    3262    the connection &SHOULD-NOT;  be considered "persistent" (<xref target="persistent.connections"/>)
    3263    after the current request/response is complete.
    3264 </t>
    3265 <t>
    3266    An HTTP/1.1 client that does not support persistent connections &MUST;
    3267    include the "close" connection option in every request message.
    3268 </t>
    3269 <t>
    3270    An HTTP/1.1 server that does not support persistent connections &MUST;
    3271    include the "close" connection option in every response message that
    3272    does not have a 1xx (Informational) status code.
    3273 </t>
    32743322</section>
    32753323
     
    33803428</t>
    33813429</section>
    3382 
    3383 
    3384 </section>
    3385 
    3386 <section title="Via" anchor="header.via">
    3387   <iref primary="true" item="Via header field" x:for-anchor=""/>
    3388   <iref primary="true" item="Header Fields" subitem="Via" x:for-anchor=""/>
    3389   <x:anchor-alias value="pseudonym"/>
    3390   <x:anchor-alias value="received-by"/>
    3391   <x:anchor-alias value="received-protocol"/>
    3392   <x:anchor-alias value="Via"/>
    3393 <t>
    3394    The "Via" header field &MUST; be sent by a proxy or gateway to
    3395    indicate the intermediate protocols and recipients between the user
    3396    agent and the server on requests, and between the origin server and
    3397    the client on responses. It is analogous to the "Received" field
    3398    used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
    3399    and is intended to be used for tracking message forwards,
    3400    avoiding request loops, and identifying the protocol capabilities of
    3401    all senders along the request/response chain.
    3402 </t>
    3403 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/>
    3404   <x:ref>Via</x:ref>               = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref>
    3405                           [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] )
    3406   <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref>
    3407   <x:ref>received-by</x:ref>       = ( <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ) / <x:ref>pseudonym</x:ref>
    3408   <x:ref>pseudonym</x:ref>         = <x:ref>token</x:ref>
    3409 </artwork></figure>
    3410 <t>
    3411    The received-protocol indicates the protocol version of the message
    3412    received by the server or client along each segment of the
    3413    request/response chain. The received-protocol version is appended to
    3414    the Via field value when the message is forwarded so that information
    3415    about the protocol capabilities of upstream applications remains
    3416    visible to all recipients.
    3417 </t>
    3418 <t>
    3419    The protocol-name is excluded if and only if it would be "HTTP". The
    3420    received-by field is normally the host and optional port number of a
    3421    recipient server or client that subsequently forwarded the message.
    3422    However, if the real host is considered to be sensitive information,
    3423    it &MAY; be replaced by a pseudonym. If the port is not given, it &MAY;
    3424    be assumed to be the default port of the received-protocol.
    3425 </t>
    3426 <t>
    3427    Multiple Via field values represent each proxy or gateway that has
    3428    forwarded the message. Each recipient &MUST; append its information
    3429    such that the end result is ordered according to the sequence of
    3430    forwarding applications.
    3431 </t>
    3432 <t>
    3433    Comments &MAY; be used in the Via header field to identify the software
    3434    of each recipient, analogous to the User-Agent and Server header fields.
    3435    However, all comments in the Via field are optional and &MAY; be removed
    3436    by any recipient prior to forwarding the message.
    3437 </t>
    3438 <t>
    3439    For example, a request message could be sent from an HTTP/1.0 user
    3440    agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
    3441    forward the request to a public proxy at p.example.net, which completes
    3442    the request by forwarding it to the origin server at www.example.com.
    3443    The request received by www.example.com would then have the following
    3444    Via header field:
    3445 </t>
    3446 <figure><artwork type="example">
    3447   Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
    3448 </artwork></figure>
    3449 <t>
    3450    A proxy or gateway used as a portal through a network firewall
    3451    &SHOULD-NOT; forward the names and ports of hosts within the firewall
    3452    region unless it is explicitly enabled to do so. If not enabled, the
    3453    received-by host of any host behind the firewall &SHOULD; be replaced
    3454    by an appropriate pseudonym for that host.
    3455 </t>
    3456 <t>
    3457    For organizations that have strong privacy requirements for hiding
    3458    internal structures, a proxy or gateway &MAY; combine an ordered
    3459    subsequence of Via header field entries with identical received-protocol
    3460    values into a single such entry. For example,
    3461 </t>
    3462 <figure><artwork type="example">
    3463   Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    3464 </artwork></figure>
    3465 <t>
    3466   could be collapsed to
    3467 </t>
    3468 <figure><artwork type="example">
    3469   Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    3470 </artwork></figure>
    3471 <t>
    3472    Senders &SHOULD-NOT; combine multiple entries unless they are all
    3473    under the same organizational control and the hosts have already been
    3474    replaced by pseudonyms. Senders &MUST-NOT; combine entries which
    3475    have different received-protocol values.
    3476 </t>
    34773430</section>
    34783431
     
    50615014<t>
    50625015  Change ABNF productions for header fields to only define the field value.
    5063   (<xref target="header.field.definitions"/>)
    50645016</t>
    50655017<t>
Note: See TracChangeset for help on using the changeset viewer.