W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] [mimesniff] Review request: Parsing a MIME type

From: Peter Occil <poccil14@gmail.com>
Date: Fri, 31 May 2013 23:50:03 -0400
Message-ID: <E2E67624B9A144F8AD9781343212B267@PeterPC>
To: "Gordon P. Hemsley" <gphemsley@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, apps-discuss@ietf.org

> * Another important point to notice is the fact that this algorithm
> allows parameter names to appear without values. This is useful in
> situations such as the "base64" option in data: URLs that use the mere
> presence or absence of a parameter to set its boolean value.

Since you mention data URLs I should note that data URLs can be percent 
encoded, which HTTP
and MIME headers can't be. This raises additional considerations when 
parsing a data URL's MIME type correctly;
see reference [1] for test cases.  In particular:

* A data URL that begins with "data:," or "data:;base64," (with no MIME 
type) is assumed to have the MIME type
  "text/plain;charset=us-ascii" under RFC2397.
* A data URL that begins with  "data:;" (with no type or subtype, but with 
parameters) is assumed to have the MIME type
  "text/plain" under RFC2397.
* The word "base64" can only appear at the end of the MIME type, so that a 
data URL like
   "data:application/example;base64;foo=bar,AA==" will not be encoded in 
base64, strictly speaking. A parameter name (base64 or otherwise)
   cannot otherwise appear without a parameter value.

[1]: http://greenbytes.de/tech/tc/datauri/
Received on Saturday, 1 June 2013 03:50:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:21 UTC