Changeset 1175 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- Mar 13, 2011, 3:41:30 PM (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1173 r1175 709 709 as a layer above some other server(s) and translates the received 710 710 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. 721 729 </t> 722 730 <t><iref primary="true" item="tunnel"/> … … 2938 2946 <section title="Header Field Definitions" anchor="header.field.definitions"> 2939 2947 <t> 2940 This section defines the syntax and semantics of HTTP /1.1header fields2948 This section defines the syntax and semantics of HTTP header fields 2941 2949 related to message framing and transport protocols. 2942 2950 </t> … … 2950 2958 <t> 2951 2959 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. 2954 2970 </t> 2955 2971 <t> … … 2962 2978 </artwork></figure> 2963 2979 <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. 2976 3015 </t> 2977 3016 <t> … … 2996 3035 include the "close" connection option in every response message that 2997 3036 does not have a 1xx (Informational) status code. 2998 </t>2999 <t>3000 A system receiving an HTTP/1.0 (or lower-version) message that3001 includes a Connection header field &MUST;, for each connection-token in this3002 field, remove and ignore any header field(s) from the message with3003 the same name as the connection-token. This protects against mistaken3004 forwarding of such header fields by pre-HTTP/1.1 proxies. See <xref target="compatibility.with.http.1.0.persistent.connections"/>.3005 3037 </t> 3006 3038 </section> … … 3470 3502 <x:anchor-alias value="Via-v"/> 3471 3503 <t> 3472 The "Via" header field &MUST; be sent by proxiesto3504 The "Via" header field &MUST; be sent by a proxy or gateway to 3473 3505 indicate the intermediate protocols and recipients between the user 3474 3506 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, 3477 3510 avoiding request loops, and identifying the protocol capabilities of 3478 3511 all senders along the request/response chain. … … 3497 3530 </t> 3498 3531 <t> 3499 The protocol-name is optionalif and only if it would be "HTTP". The3532 The protocol-name is excluded if and only if it would be "HTTP". The 3500 3533 received-by field is normally the host and optional port number of a 3501 3534 recipient server or client that subsequently forwarded the message. … … 3505 3538 </t> 3506 3539 <t> 3507 Multiple Via field values represent each proxy that has3540 Multiple Via field values represent each proxy or gateway that has 3508 3541 forwarded the message. Each recipient &MUST; append its information 3509 3542 such that the end result is ordered according to the sequence of … … 3512 3545 <t> 3513 3546 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. 3518 3550 </t> 3519 3551 <t> … … 3529 3561 </artwork></figure> 3530 3562 <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. 3537 3568 </t> 3538 3569 <t> 3539 3570 For organizations that have strong privacy requirements for hiding 3540 internal structures, a proxy &MAY; combine an ordered subsequence of3541 Via header field entries with identical received-protocol values into3542 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, 3543 3574 </t> 3544 3575 <figure><artwork type="example"> … … 3552 3583 </artwork></figure> 3553 3584 <t> 3554 Applications &SHOULD-NOT;combine multiple entries unless they are all3585 Senders &SHOULD-NOT; combine multiple entries unless they are all 3555 3586 under the same organizational control and the hosts have already been 3556 replaced by pseudonyms. Applications &MUST-NOT; combine entries which3587 replaced by pseudonyms. Senders &MUST-NOT; combine entries which 3557 3588 have different received-protocol values. 3558 3589 </t>
Note: See TracChangeset
for help on using the changeset viewer.