Ignore:
Timestamp:
13/03/11 22:41:30 (11 years ago)
Author:
fielding@…
Message:

On second thought, gateways behave like user agents on the
inbound connection since they decide the inbound target resource.
The distinction is that HTTP-to-HTTP gateways must also implement
Connection and Via. Revises [1173] accordingly.

Improve definition of Connection header field to require that
the Conection field itself be removed (how did we forget that?)
and note the overlap between connection-token and field-name
namespaces. Addresses one half of #256 and #231.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1173 r1175  
    709709   as a layer above some other server(s) and translates the received
    710710   requests to the underlying server's protocol.  Gateways are often
    711    used for load balancing, "accelerator" caching, or partitioning
    712    HTTP services across multiple machines.  Gateways behave as an origin
    713    server on the outbound connection and as a proxy on the inbound
    714    connection.  All HTTP requirements applicable to an origin server
    715    also apply to the outbound communication of a gateway.  A gateway
    716    communicates with inbound servers using any protocol it desires,
    717    including private extensions to HTTP that are outside the scope of
    718    this specification.  However, an HTTP-to-HTTP gateway that wishes
    719    to interoperate with third-party HTTP servers &SHOULD; comply with
    720    HTTP proxy requirements on the gateway's inbound connection.
     711   used to encapsulate legacy or untrusted information services, to
     712   improve server performance through "accelerator" caching, and to
     713   enable partitioning or load-balancing of HTTP services across
     714   multiple machines.
     715</t>
     716<t>
     717   A gateway behaves as an origin server on its outbound connection and
     718   as a user agent on its inbound connection.
     719   All HTTP requirements applicable to an origin server
     720   also apply to the outbound communication of a gateway.
     721   A gateway communicates with inbound servers using any protocol that
     722   it desires, including private extensions to HTTP that are outside
     723   the scope of this specification.  However, an HTTP-to-HTTP gateway
     724   that wishes to interoperate with third-party HTTP servers &MUST;
     725   comply with HTTP user agent requirements on the gateway's inbound
     726   connection and &MUST; implement the Connection
     727   (<xref target="header.connection"/>) and Via (<xref target="header.via"/>)
     728   header fields for both connections.
    721729</t>
    722730<t><iref primary="true" item="tunnel"/>
    … …  
    29382946<section title="Header Field Definitions" anchor="header.field.definitions">
    29392947<t>
    2940    This section defines the syntax and semantics of HTTP/1.1 header fields
     2948   This section defines the syntax and semantics of HTTP header fields
    29412949   related to message framing and transport protocols.
    29422950</t>
    … …  
    29502958<t>
    29512959   The "Connection" header field allows the sender to specify
    2952    options that are desired for that particular connection and &MUST-NOT;
    2953    be communicated by proxies over further connections.
     2960   options that are desired only for that particular connection.
     2961   Such connection options &MUST; be removed or replaced before the
     2962   message can be forwarded downstream by a proxy or gateway.
     2963   This mechanism also allows the sender to indicate which HTTP
     2964   header fields used in the message are only intended for the
     2965   immediate recipient ("hop-by-hop"), as opposed to all recipients
     2966   on the chain ("end-to-end"), enabling the message to be
     2967   self-descriptive and allowing future connection-specific extensions
     2968   to be deployed in HTTP without fear that they will be blindly
     2969   forwarded by previously deployed intermediaries.
    29542970</t>
    29552971<t>
    … …  
    29622978</artwork></figure>
    29632979<t>
    2964    HTTP/1.1 proxies &MUST; parse the Connection header field before a
    2965    message is forwarded and, for each connection-token in this field,
    2966    remove any header field(s) from the message with the same name as the
    2967    connection-token. Connection options are signaled by the presence of
    2968    a connection-token in the Connection header field, not by any
    2969    corresponding additional header field(s), since the additional header
    2970    field might not be sent if there are no parameters associated with that
    2971    connection option.
    2972 </t>
    2973 <t>
    2974    Message header fields listed in the Connection header field &MUST-NOT; include
    2975    end-to-end header fields, such as Cache-Control (&header-cache-control;).
     2980   A proxy or gateway &MUST; parse a received Connection
     2981   header field before a message is forwarded and, for each
     2982   connection-token in this field, remove any header field(s) from
     2983   the message with the same name as the connection-token, and then
     2984   remove the Connection header field itself or replace it with the
     2985   sender's own connection options for the forwarded message.
     2986</t>
     2987<t>
     2988   A sender &MUST-NOT; include field-names in the Connection header
     2989   field-value for fields that are defined as expressing constraints
     2990   for all recipients in the request or response chain, such as the
     2991   Cache-Control header field (&header-cache-control;).
     2992</t>
     2993<t>
     2994   The connection options do not have to correspond to a header field
     2995   present in the message, since a connection-specific header field
     2996   might not be needed if there are no parameters associated with that
     2997   connection option.  Recipients that trigger certain connection
     2998   behavior based on the presence of connection options &MUST; do so
     2999   based on the presence of the connection-token rather than only the
     3000   presence of the optional header field.  In other words, if the
     3001   connection option is received as a header field but not indicated
     3002   within the Connection field-value, then the recipient &MUST; ignore
     3003   the connection-specific header field because it has likely been
     3004   forwarded by an intermediary that is only partially compliant.
     3005</t>
     3006<t>
     3007   When defining new connection options, specifications ought to
     3008   carefully consider existing deployed header fields and ensure
     3009   that the new connection-token does not share the same name as
     3010   an unrelated header field that might already be deployed.
     3011   Defining a new connection-token essentially reserves that potential
     3012   field-name for carrying additional information related to the
     3013   connection option, since it would be unwise for senders to use
     3014   that field-name for anything else.
    29763015</t>
    29773016<t>
    … …  
    29963035   include the "close" connection option in every response message that
    29973036   does not have a 1xx (Informational) status code.
    2998 </t>
    2999 <t>
    3000    A system receiving an HTTP/1.0 (or lower-version) message that
    3001    includes a Connection header field &MUST;, for each connection-token in this
    3002    field, remove and ignore any header field(s) from the message with
    3003    the same name as the connection-token. This protects against mistaken
    3004    forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>.
    30053037</t>
    30063038</section>
    … …  
    34703502  <x:anchor-alias value="Via-v"/>
    34713503<t>
    3472    The "Via" header field &MUST; be sent by proxies to
     3504   The "Via" header field &MUST; be sent by a proxy or gateway to
    34733505   indicate the intermediate protocols and recipients between the user
    34743506   agent and the server on requests, and between the origin server and
    3475    the client on responses. It is analogous to the "Received" field defined in
    3476    <xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/> and is intended to be used for tracking message forwards,
     3507   the client on responses. It is analogous to the "Received" field
     3508   used by email systems (<xref target="RFC5322" x:fmt="of" x:sec="3.6.7"/>)
     3509   and is intended to be used for tracking message forwards,
    34773510   avoiding request loops, and identifying the protocol capabilities of
    34783511   all senders along the request/response chain.
    … …  
    34973530</t>
    34983531<t>
    3499    The protocol-name is optional if and only if it would be "HTTP". The
     3532   The protocol-name is excluded if and only if it would be "HTTP". The
    35003533   received-by field is normally the host and optional port number of a
    35013534   recipient server or client that subsequently forwarded the message.
    … …  
    35053538</t>
    35063539<t>
    3507    Multiple Via field values represent each proxy that has
     3540   Multiple Via field values represent each proxy or gateway that has
    35083541   forwarded the message. Each recipient &MUST; append its information
    35093542   such that the end result is ordered according to the sequence of
    … …  
    35123545<t>
    35133546   Comments &MAY; be used in the Via header field to identify the software
    3514    of the recipient proxy, analogous to the User-Agent and
    3515    Server header fields. However, all comments in the Via field are
    3516    optional and &MAY; be removed by any recipient prior to forwarding the
    3517    message.
     3547   of each recipient, analogous to the User-Agent and Server header fields.
     3548   However, all comments in the Via field are optional and &MAY; be removed
     3549   by any recipient prior to forwarding the message.
    35183550</t>
    35193551<t>
    … …  
    35293561</artwork></figure>
    35303562<t>
    3531    Proxies used as a portal through a network firewall
    3532    &SHOULD-NOT;, by default, forward the names and ports of hosts within
    3533    the firewall region. This information &SHOULD; only be propagated if
    3534    explicitly enabled. If not enabled, the received-by host of any host
    3535    behind the firewall &SHOULD; be replaced by an appropriate pseudonym
    3536    for that host.
     3563   A proxy or gateway used as a portal through a network firewall
     3564   &SHOULD-NOT; forward the names and ports of hosts within the firewall
     3565   region unless it is explicitly enabled to do so. If not enabled, the
     3566   received-by host of any host behind the firewall &SHOULD; be replaced
     3567   by an appropriate pseudonym for that host.
    35373568</t>
    35383569<t>
    35393570   For organizations that have strong privacy requirements for hiding
    3540    internal structures, a proxy &MAY; combine an ordered subsequence of
    3541    Via header field entries with identical received-protocol values into
    3542    a single such entry. For example,
     3571   internal structures, a proxy or gateway &MAY; combine an ordered
     3572   subsequence of Via header field entries with identical received-protocol
     3573   values into a single such entry. For example,
    35433574</t>
    35443575<figure><artwork type="example">
    … …  
    35523583</artwork></figure>
    35533584<t>
    3554    Applications &SHOULD-NOT; combine multiple entries unless they are all
     3585   Senders &SHOULD-NOT; combine multiple entries unless they are all
    35553586   under the same organizational control and the hosts have already been
    3556    replaced by pseudonyms. Applications &MUST-NOT; combine entries which
     3587   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
    35573588   have different received-protocol values.
    35583589</t>
Note: See TracChangeset for help on using the changeset viewer.