[EMAIL PROTECTED]! grr... darin
[EMAIL PROTECTED] wrote: > I'm planning to rev nsIIOService in preparation for marking it frozen by > Mozilla 1.2. See http://bugzilla.mozilla.org/show_bug.cgi?id=157131. > > Unfortunately, nsIIOService has been the dumping ground in necko for > miscellaneous functions. I'm hoping to eliminate some of the cruft. > > I'm planning on dropping the following methods: > > GetParserForScheme - this function is unused outside necko, but > more importantly it exposes nsIURLParser, > which is more or less a necko implementation > detail. not all protocols register a > nsIURLParser, and as a result the default > nsIURLParser implementation is often used. > the default nsIURLParser implementation is > therefore not guaranteed compatible with the > nsIURI implementation returned from > nsIProtocolHandler::NewURI. Eliminating this > API therefore closes the potential security > risk of this API (e.g., two components may > parse the same URL string differently leading > to broken security checks). > > ExtractUrlPart - this function is commonly used to > "efficiently" parse an arbitrary URL string > without the overhead of calling > nsIProtocolHandler::NewURI. this function > depends on the result returned from > GetParserForScheme and therefore suffers the > same potential security risk. the performance > benefits (i'll assert that these are minor) do > not outweigh the potential security risk > levied by this interface on unsuspecting > components (especially those developed > externally without the review of mozilla > developers well aware of such security > issues). > > ResolveRelativePath - this is only used internally by necko to > implement the JAR protocol handler. there is > no need to expose this utility function on > nsIIOService. > > I'm also proposing a change to this method: > > void initFileFromURLSpec(in nsIFile file, in AUTF8String url); > > This method should be modified to return a nsIFile instead of expecting > one to be preallocated by the caller. This interface breaks the > abstraction of the nsIFile interface since it requires a caller to know > apriori that the URL corresponds to a local file. dougt suggested the > following signature instead: > > nsIFile getFileFromURLSpec(in AUTF8String url); > > A little LXR'ing should confirm that this isn't going to cause too much > trouble for existing mozilla components. > > I'll also be rev'ing the IID, CID, and ContractID along with these > changes. That should minimize crashes resulting from plugins and other > external components leveraging the current "unfrozen" nsIIOService > interface. They just won't work ;-) > > Darin >
