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
