Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
framework-3.0.8
-
None
Description
The call Bundle.getResource("/") returns a valid URL, but the only purpose of this URL is to be used as context for building URLs to other entries in the bundle. The "/" URL doesn't actually exist, so any attempt to open it should fail. Unfortunately, this isn't always the case.
For a little background, bundle resource URLs can have multiple roots for each entry on the bundle class path, so just construction a bundle resource URL from another one may not give you what you want since it may not be using the correct index into the bundle class path (since bundle resource URLs are opaque, the user can't be expected to understand this). So, we try to be nice in the URLHandlersBundleURLConnection constructor and detect this case and automatically fix the class path index.
When this "nice" hack is combined with someone opening the "/" resource URL, we can run into an issue. Since "/" never exists, the "nice" hack in URLHandlersBundleURLConnection kicks in and searches for it in other bundle class path entries. If one of these bundle class path entries is an embedded directory, then the "/" effectively gets converted to the embedded directory entry, since ContentDirectoryContent prepends the embedded directory when searching. Since the embedded directory does exist, it then becomes possible to create an input stream to it, which to the user will appear as if is created an input stream to "/". This is not correct for a variety of reasons.
To avoid this, we should modify the URLHandlersBundleURLConnection constructor to explicitly check for the "/" URL and always throw an exception in this case immediately, to ensure that no one can ever open a connection to it. This also avoids the possibility that we will try find it another way with our "nice" hack.