14.9.5 No-Transform Directive

   Implementers of intermediate caches (proxies) have found it useful to
   convert the media type of certain entity bodies. A proxy might, for
   example, convert between image formats in order to save cache space
   or to reduce the amount of traffic on a slow link. HTTP has to date
   been silent on these transformations.





Fielding, et. al.           Standards Track                   [Page 107]

RFC 2068                        HTTP/1.1                    January 1997


   Serious operational problems have already occurred, however, when
   these transformations have been applied to entity bodies intended for
   certain kinds of applications. For example, applications for medical
   imaging, scientific data analysis and those using end-to-end
   authentication, all depend on receiving an entity body that is bit
   for bit identical to the original entity-body.

   Therefore, if a response includes the no-transform directive, an
   intermediate cache or proxy MUST NOT change those headers that are
   listed in section 13.5.2 as being subject to the no-transform
   directive.  This implies that the cache or proxy must not change any
   aspect of the entity-body that is specified by these headers.

14.9.6 Cache Control Extensions

   The Cache-Control header field can be extended through the use of one
   or more cache-extension tokens, each with an optional assigned value.
   Informational extensions (those which do not require a change in
   cache behavior) may be added without changing the semantics of other
   directives. Behavioral extensions are designed to work by acting as
   modifiers to the existing base of cache directives. Both the new
   directive and the standard directive are supplied, such that
   applications which do not understand the new directive will default
   to the behavior specified by the standard directive, and those that
   understand the new directive will recognize it as modifying the
   requirements associated with the standard directive.  In this way,
   extensions to the Cache-Control directives can be made without
   requiring changes to the base protocol.

   This extension mechanism depends on a HTTP cache obeying all of the
   cache-control directives defined for its native HTTP-version, obeying
   certain extensions, and ignoring all directives that it does not
   understand.

   For example, consider a hypothetical new response directive called
   "community" which acts as a modifier to the "private" directive. We
   define this new directive to mean that, in addition to any non-shared
   cache, any cache which is shared only by members of the community
   named within its value may cache the response. An origin server
   wishing to allow the "UCI" community to use an otherwise private
   response in their shared cache(s) may do so by including

          Cache-Control: private, community="UCI"

   A cache seeing this header field will act correctly even if the cache
   does not understand the "community" cache-extension, since it will
   also see and understand the "private" directive and thus default to
   the safe behavior.



Fielding, et. al.           Standards Track                   [Page 108]

RFC 2068                        HTTP/1.1                    January 1997


   Unrecognized cache-directives MUST be ignored; it is assumed that any
   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
   be combined with standard directives (or the response's default
   cachability) such that the cache behavior will remain minimally
   correct even if the cache does not understand the extension(s).

14.10 Connection

   The Connection general-header field allows the sender to specify
   options that are desired for that particular connection and MUST NOT
   be communicated by proxies over further connections.

   The Connection header has the following grammar:

          Connection-header = "Connection" ":" 1#(connection-token)
          connection-token  = token

   HTTP/1.1 proxies MUST parse the Connection header field before a
   message is forwarded and, for each connection-token in this field,
   remove any header field(s) from the message with the same name as the
   connection-token. Connection options are signaled by the presence of
   a connection-token in the Connection header field, not by any
   corresponding additional header field(s), since the additional header
   field may not be sent if there are no parameters associated with that
   connection option.  HTTP/1.1 defines the "close" connection option
   for the sender to signal that the connection will be closed after
   completion of the response. For example,

          Connection: close

   in either the request or the response header fields indicates that
   the connection should not be considered `persistent' (section 8.1)
   after the current request/response is complete.

   HTTP/1.1 applications that do not support persistent connections MUST
   include the "close" connection option in every message.