Darin Fisher wrote:
Another option would be to have necko automagically wedge an instance of nsUnknownDecoder between the file channel and its listener. This is already done for HTTP (and elsewhere i think). BZ might even have a bug filed about doing this.
Not really. One interesting related bug that I ran into today is bug 61855.
Basically, there are cases when one would want to know the MIME type of a file without actually opening a file channel (eg bug 61855). At the same time, not all files can be "rewound" once you read a bit from them (eg named pipes).
So we have a few options... we could add sniffing to GetTypeFromFile and accept the fact that calling GetTypeFromFile on a pipe will lead to dataloss. We could add the sniffing to the file:// channel (and maybe push some knowledge of nsIFileURL into the unknown decoder in the process) and make consumers who really care (like form submission) either open file:// channels or sniff their data themselves (this would require nsUnknownDecoder to support Convert(), not just AsyncConvertData()).
I'm not quite sure which of these options I most dislike so far.... ;)
-Boris
P.S. No need to cc me -- I'm subbed to mozilla-netlib
well, we can learn if a file is a named pipe or not just by doing a stat (see nsIFile::isSpecial). for normal files, we could just go ahead and sniff the file contents.
darin
