received via HTTP. Data in character sets other than "ISO-8859-1" or
   its subsets MUST be labeled with an appropriate charset value. See
   section 3.4.1 for compatibility problems.

3.7.2 Multipart Types

   MIME provides for a number of "multipart" types -- encapsulations of
   one or more entities within a single message-body. All multipart
   types share a common syntax, as defined in section 5.1.1 of RFC 2046




 
RFC 2616                        HTTP/1.1                       June 1999


   [40], and MUST include a boundary parameter as part of the media type
   value. The message body is itself a protocol element and MUST
   therefore use only CRLF to represent line breaks between body-parts.
   Unlike in RFC 2046, the epilogue of any multipart message MUST be
   empty; HTTP applications MUST NOT transmit the epilogue (even if the
   original multipart contains an epilogue). These restrictions exist in
   order to preserve the self-delimiting nature of a multipart message-
   body, wherein the "end" of the message-body is indicated by the
   ending multipart boundary.

   In general, HTTP treats a multipart message-body no differently than
   any other media type: strictly as payload. The one exception is the
   "multipart/byteranges" type (appendix 19.2) when it appears in a 206
   (Partial Content) response, which will be interpreted by some HTTP
   caching mechanisms as described in sections 13.5.4 and 14.16. In all
   other cases, an HTTP user agent SHOULD follow the same or similar
   behavior as a MIME user agent would upon receipt of a multipart type.
   The MIME header fields within each body-part of a multipart message-
   body do not have any significance to HTTP beyond that defined by
   their MIME semantics.

   In general, an HTTP user agent SHOULD follow the same or similar
   behavior as a MIME user agent would upon receipt of a multipart type.
   If an application receives an unrecognized multipart subtype, the
   application MUST treat it as being equivalent to "multipart/mixed".

      Note: The "multipart/form-data" type has been specifically defined
      for carrying form data suitable for processing via the POST
      request method, as described in RFC 1867 [15].

3.8 Product Tokens

   Product tokens are used to allow communicating applications to
   identify themselves by software name and version. Most fields using
   product tokens also allow sub-products which form a significant part
   of the application to be listed, separated by white space. By
   convention, the products are listed in order of their significance
   for identifying the application.

       product         = token ["/" product-version]
       product-version = token

   Examples:

       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
       Server: Apache/0.8.4






 
RFC 2616                        HTTP/1.1                       June 1999


   Product tokens SHOULD be short and to the point. They MUST NOT be
   used for advertising or other non-essential information. Although any
   token character MAY appear in a product-version, this token SHOULD
   only be used for a version identifier (i.e., successive versions of
   the same product SHOULD only differ in the product-version portion of
   the product value).

3.9 Quality Values

   HTTP content negotiation (section 12) uses short "floating point"
   numbers to indicate the relative importance ("weight") of various
   negotiable parameters.  A weight is normalized to a real number in
   the range 0 through 1, where 0 is the minimum and 1 the maximum
   value. If a parameter has a quality value of 0, then content with
   this parameter is `not acceptable' for the client. HTTP/1.1
   applications MUST NOT generate more than three digits after the
   decimal point. User configuration of these values SHOULD also be
   limited in this fashion.

       qvalue         = ( "0" [ "." 0*3DIGIT ] )
                      | ( "1" [ "." 0*3("0") ] )

   "Quality values" is a misnomer, since these values merely represent
   relative degradation in desired quality.

3.10 Language Tags