Closed
Bug 221708
Opened 21 years ago
Closed 20 years ago
file handling APIs fail to deal with non-ascii extensions
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
People
(Reporter: Biesinger, Unassigned)
Details
http://lxr.mozilla.org/seamonkey/source/netwerk/mime/public/nsIMIMEInfo.idl#64 http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsIExternalHelperAppService.idl all of those use |string| for extensions. better would be AString or wstring, so that the APIs support non-ascii characters.
Comment 1•21 years ago
|
||
Quite frankly, do these come up? What charset do we assume the extension from nsIURL is in?
Reporter | ||
Comment 2•21 years ago
|
||
>Quite frankly, do these come up? if a server sends them... I haven't seen any yet, but they aren't prohibited. also if an application decides to use them, but I haven't seen such an application either >What charset do we assume the extension from nsIURL is in? ASCII, it seems. at least we pass it through |string| parameters. On the other hand, we don't unescape it.
Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #1) > Quite frankly, do these come up? apparently, at one time you were convinced of that ;) *** This bug has been marked as a duplicate of 80787 ***
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•