Bug 908 - Gluegen doesn't handle URI escaping of reserved character accurately, i.e. double escaping is performed on e.g. '#'.
Summary: Gluegen doesn't handle URI escaping of reserved character accurately, i.e. do...
Alias: None
Product: Gluegen
Classification: JogAmp
Component: core (show other bugs)
Version: 2
Hardware: pc_all all
: --- minor
Assignee: Sven Gothel
Depends on:
Blocks: 1063 1103 1109
  Show dependency treegraph
Reported: 2013-11-20 11:25 CET by Brice Figureau
Modified: 2014-12-11 17:57 CET (History)
3 users (show)

See Also:
Type: ---
SCM Refs:
Workaround: ---

gluegen debug output (11.64 KB, text/x-log)
2013-11-20 11:25 CET, Brice Figureau

Note You need to log in before you can comment on or make changes to this bug.
Description Brice Figureau 2013-11-20 11:25:57 CET
Created attachment 546 [details]
gluegen debug output

We have a customer that have installed our game in the I:\#SPIELE\ folder on his windows computer. Our game is not able to load the joal native libraries because of this exception (it's the same for the other native libraries):

java.lang.IllegalArgumentException: URI has a fragment component
	at java.io.File.<init>(Unknown Source)
	at com.jogamp.common.util.IOUtil.toURL(IOUtil.java:534)
	at com.jogamp.common.util.JarUtil.getJarFile(JarUtil.java:454)
	at com.jogamp.common.util.cache.TempJarCache.addNativeLibs(TempJarCache.java:211)
	at com.jogamp.common.jvm.JNILibLoaderBase.addNativeJarLibsImpl(JNILibLoaderBase.java:196)
	at com.jogamp.common.jvm.JNILibLoaderBase.addNativeJarLibs(JNILibLoaderBase.java:368)
	at com.jogamp.common.os.Platform$1.run(Platform.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at com.jogamp.common.os.Platform.<clinit>(Platform.java:173)
	at com.jogamp.openal.ALFactory.<clinit>(ALFactory.java:67)
	at com.daysofwonder.gamelib.OpenALSoundEngine.initOpenAL(OpenALSoundEngine.java:133)
	at com.daysofwonder.gamelib.OpenALSoundEngine.init(OpenALSoundEngine.java:217)
	at com.daysofwonder.application.GameApplication.startAudio(GameApplication.java:150)
	at com.daysofwonder.tt.application.TTApplication.start(TTApplication.java:306)
	at com.daysofwonder.tt.application.TTApplication.main(TTApplication.java:752)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.exe4j.runtime.LauncherEngine.launch(Unknown Source)
	at com.exe4j.runtime.WinLauncher.main(Unknown Source)
	at com.install4j.runtime.launcher.WinLauncher.main(Unknown Source)

We might be missing a kind of urlencode somewhere.
I've added the whole gluegen debug output, too.
Comment 1 Sven Gothel 2013-11-28 12:59:24 CET
Evaluated behavior on GNU/Linux and WIndows.

- 'new File(path_with_#)' fails on both platforms
- 'new URL(path_with_#)' and subsequent JARFile loading:
  - Windows ERROR

gluegen commit 4c835f0337674a0181c43f448d44d961e27b2f54
uses uri.getPath() and decodes it explicitly leading to a unified behavior, i.e.:
  - Windows ERROR
In short: We cannot support a '#' in URI/URL since it denominates a fragment
and using such fails within the URI/URL implementation itself.

Iff we fix this - we would need to overhaul all URI usage, probably utilizing a 
different implementation, e.g. <http://jena.sourceforge.net/iri/documentation.html>.
Comment 2 Andy Skinner 2014-09-03 17:14:15 CEST
We had problems with these characters:
$ ^ ~ # [ ]

I'm checking about the specifics of them, whether they were the same issue, etc.
Comment 3 Andy Skinner 2014-09-03 20:50:50 CEST
Specifically, we had the jar files in directories named "R$", "R^", "R#", "R[", and "R]".  I don't know whether there are other combinations of these that would be bad.  Just that someone tested installing into directories with these characters in the name, and had problems.
Comment 4 Sven Gothel 2014-09-07 08:06:09 CEST

Fix URI/URL double encoding, 
ensuring encoded/decoded variants are used properly (Added unit test)
Bug 908 was caused by confusing URI encoded parts (e.g. scheme-specific-part) and it's decoded variant.
This especially happened due to:
  - the fact, that the encoded and unencoded variant uses the same String type,
  - the URI/URL decoding differs, is not complete 
    (e.g. %20 .. SPACE remains in decoded part),
  - and does not comply w/ RFC 2396 and RFC 3986 (encoding), 
    e.g. not all RESERVED chars are encoded.
In branch 'v2.3.0_branch', we will introduce our own Uri and Uri.Encoded class
to solve above issue by replacing all URI usage w/ Uri,
see Bug 1063
 - Backporting results of own Uri class introduction in branch 'v2.3.0_branch'
 - Ensure the encoded URI parts are used where required, 
   i.e. IOUtil.compose(..) etc
 - TestNetIOURIReservedCharsBug908: Automated test, 
   launching GlueGen jar file from an <i>odd pathname</i>.