[Framework] It should not be possible to open an URLConnection to "/" for a
bundle URL
--------------------------------------------------------------------------------------
Key: FELIX-2832
URL: https://issues.apache.org/jira/browse/FELIX-2832
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-3.0.8
Reporter: Richard S. Hall
Assignee: Richard S. Hall
Priority: Minor
Fix For: framework-3.2.0
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
