Ignore:
Timestamp:
04/11/13 23:28:11 (7 years ago)
Author:
fielding@…
Message:

reduce two MUSTs to a clarified ought; addresses #502

File:
1 edited

Legend:

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

    r2468 r2471  
    21312131            <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>).
    21322132            </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.
    21442142            </p>
    21452143            <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.
Note: See TracChangeset for help on using the changeset viewer.