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

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

From: Gordon P. Hemsley <gphemsley@gmail.com>
Date: Sat, 1 Jun 2013 11:51:21 -0400
Message-ID: <CAH4e3M6GkMFMryQ70cOz7C9ANoFh9_9hp5+kSDL4QNOuAxKBZg@mail.gmail.com>
To: Peter Occil <poccil14@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, apps-discuss@ietf.org
On Sat, Jun 1, 2013 at 11:41 AM, Gordon P. Hemsley <gphemsley@gmail.com> wrote:
> On Fri, May 31, 2013 at 11:50 PM, Peter Occil <poccil14@gmail.com> wrote:
>> * 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.
>
> As I mentioned, "strictly speaking" doesn't matter, as all browsers do
> the same thing, according to the resource you linked: base64
> parameters with values are fine; base64 boolean parameters in other
> than last place are warnings. (Not sure what the reasoning behind that
> distinction is, but that's what reality is.)

It seems I read the purpose of the test wrong for base64 parameters
with values: They're fine insofar as they're allowed, but they don't
trigger base64 decoding (except in Safari?), unlike if the boolean
base64 parameter is in a non-last position.

--
Gordon P. Hemsley
me@gphemsley.org
http://gphemsley.org/http://gphemsley.org/blog/
Received on Saturday, 1 June 2013 15:52:07 UTC

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