Network Working Group R. Fielding Request for Comments: 2616 ...

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 HTTPcaching mechanisms as described in sections 13.5.4 and 14.16. In allother cases, an HTTP user agent SHOULD follow the same or similarbehavior as a MIME user agent would upon receipt of a multipart type.The MIME header fields within each body-part of a multipart messagebodydo not have any significance to HTTP beyond that defined bytheir MIME semantics.In general, an HTTP user agent SHOULD follow the same or similarbehavior as a MIME user agent would upon receipt of a multipart type.If an application receives an unrecognized multipart subtype, theapplication MUST treat it as being equivalent to "multipart/mixed".Note: The "multipart/form-data" type has been specifically definedfor carrying form data suitable for processing via the POSTrequest method, as described in RFC 1867 [15].3.8 Product TokensProduct tokens are used to allow communicating applications toidentify themselves by software name and version. Most fields usingproduct tokens also allow sub-products which form a significant partof the application to be listed, separated by white space. Byconvention, the products are listed in order of their significancefor identifying the application.productproduct-version = token= token ["/" product-version]Examples:User-Agent: CERN-LineMode/2.15 libwww/2.17b3Server: Apache/0.8.4Fielding, et al. Standards Track [Page 28]RFC 2616 HTTP/1.1 June 1999Product tokens SHOULD be short and to the point. They MUST NOT beused for advertising or other non-essential information. Although anytoken character MAY appear in a product-version, this token SHOULDonly be used for a version identifier (i.e., successive versions ofthe same product SHOULD only differ in the product-version portion ofthe product value).