W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

[widgets] Potential bug in Rule for Identifying the Media Type of a File

From: Marcos Caceres <marcosc@opera.com>
Date: Tue, 29 Sep 2009 16:50:30 +0200
Message-ID: <b21a10670909290750l291dc174m5c9f686cdbad0f74@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
Hi, I think I found another bug :(

The current ABNF for a zip relative path allows the first character of
a file name to be a ".".

So, imagine you have a file in the zip archive called ".jpg" which is
actually a text file.

In the Rule for Identifying the Media Type of a File, it reads:

1. Let file be the file to be processed. (in this case, ".jpg")
2. If file has a file-extension, attempt to match the file-extension
to one in the file extensions column in the file identification table.
If there is a match, then return the media type value. (returns
"image/jpeg")
3. If file extension is absent, the media type of a file is determined
by using the rules set forth in the [SNIFF] specification.

So, the rule has incorrectly matched the type and returns "image/jpeg".

Options:

1. Disallow "." in the base-name of a file (this means that files
named "a...b...c." will be ignored, and so are any file starting with
a ".": ".foobar").
2. Modify 2 above to say:
  " If file has a file-extension and a base-name, ... "
  And modify 3, to say "Otherwise, the media type of a file is
determined by using the rules set forth in the [SNIFF] specification."

However, because of the ambiguity caused by allowing "." in base
names, it is basically not possible to determine if the "file
extension" of a file is in fact a file extension or a base name.

Unsure how to proceed as it is likely that ".filename" type files will
end up in widget packages.... it might be safe for user agents to
ignore those files.

-- 
Marcos Caceres
http://datadriven.com.au
Received on Tuesday, 29 September 2009 14:51:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT