- From: Marcos Caceres <marcosc@opera.com>
- Date: Tue, 29 Sep 2009 16:50:30 +0200
- 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 UTC