Changeset 2471
- Timestamp:
- 04/11/13 23:28:11 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2468 r2471 2131 2131 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a> is never appropriate as a connection option (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2132 2132 </p> 2133 <p id="rfc.section.6.1.p.8">The connection options do not have to correspond to a header field present in the message, since a connection-specific header 2134 field might not be needed if there are no parameters associated with that connection option. Recipients that trigger certain 2135 connection behavior based on the presence of connection options <em class="bcp14">MUST</em> do so based on the presence of the connection-option rather than only the presence of the optional header field. In other 2136 words, if the connection option is received as a header field but not indicated within the Connection field-value, then the 2137 recipient <em class="bcp14">MUST</em> ignore the connection-specific header field because it has likely been forwarded by an intermediary that is only partially 2138 conformant. 2139 </p> 2140 <p id="rfc.section.6.1.p.9">When defining new connection options, specifications ought to carefully consider existing deployed header fields and ensure 2141 that the new connection option does not share the same name as an unrelated header field that might already be deployed. Defining 2142 a new connection option essentially reserves that potential field-name for carrying additional information related to the 2143 connection option, since it would be unwise for senders to use that field-name for anything else. 2133 <p id="rfc.section.6.1.p.8">The connection options do not always correspond to a header field present in the message, since a connection-specific header 2134 field might not be needed if there are no parameters associated with a connection option. In contrast, a connection-specific 2135 header field that is received without a corresponding connection option usually indicates that the field has been improperly 2136 forwarded by an intermediary and ought to be ignored by the recipient. 2137 </p> 2138 <p id="rfc.section.6.1.p.9">When defining new connection options, specification authors ought to survey existing header field names and ensure that the 2139 new connection option does not share the same name as an already deployed header field. Defining a new connection option essentially 2140 reserves that potential field-name for carrying additional information related to the connection option, since it would be 2141 unwise for senders to use that field-name for anything else. 2144 2142 </p> 2145 2143 <p id="rfc.section.6.1.p.10">The "<dfn>close</dfn>" connection option is defined for a sender to signal that this connection will be closed after completion of the response. -
draft-ietf-httpbis/latest/p1-messaging.xml
r2468 r2471 2881 2881 </t> 2882 2882 <t> 2883 The connection options do not have tocorrespond to a header field2883 The connection options do not always correspond to a header field 2884 2884 present in the message, since a connection-specific header field 2885 might not be needed if there are no parameters associated with that 2886 connection option. Recipients that trigger certain connection 2887 behavior based on the presence of connection options &MUST; do so 2888 based on the presence of the connection-option rather than only the 2889 presence of the optional header field. In other words, if the 2890 connection option is received as a header field but not indicated 2891 within the Connection field-value, then the recipient &MUST; ignore 2892 the connection-specific header field because it has likely been 2893 forwarded by an intermediary that is only partially conformant. 2894 </t> 2895 <t> 2896 When defining new connection options, specifications ought to 2897 carefully consider existing deployed header fields and ensure 2898 that the new connection option does not share the same name as 2899 an unrelated header field that might already be deployed. 2885 might not be needed if there are no parameters associated with a 2886 connection option. In contrast, a connection-specific header field that 2887 is received without a corresponding connection option usually indicates 2888 that the field has been improperly forwarded by an intermediary and 2889 ought to be ignored by the recipient. 2890 </t> 2891 <t> 2892 When defining new connection options, specification authors ought to survey 2893 existing header field names and ensure that the new connection option does 2894 not share the same name as an already deployed header field. 2900 2895 Defining a new connection option essentially reserves that potential 2901 2896 field-name for carrying additional information related to the
Note: See TracChangeset
for help on using the changeset viewer.