2017-01-17 22:19 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 17/01/2017 18:07, Christopher Schultz wrote: >> Mark, >> >> On 1/16/17 6:24 AM, Mark Thomas wrote: >>> For the background see: >>> https://github.com/spring-projects/spring-boot/issues/7949 >>> >>> The short version is: >>> >>> * is seen as a wild card in some environments. >>> >>> The options are: >>> $ & ' ( ) * , - . : ; @ _ ~ >>> (all followed by /) >> >> Obviously you can't use "." since that is in 99% of WAR filenames. The >> ";" character is used for file-versions in VMS. I'm not sure how many >> VMS environments are running Tomcat, but ... it's a thing. Hyphen (-) >> and underscore (_) are probably too popular. I'd say that $ & : @ * are >> good contenders. But we are trying to replace * no? >> >>> Ideally we want a character that: >>> - is unlikely to appear in a file name (particularly at the end) >>> - does not have a special meaning that could conflict when using it in >>> combination with / in a URI to mark the start of the internal WAR path. >>> >>> Thoughts, comments, reasons for excluding one or more of these >>> characters welcome. >> >> So you want a character that can be used in the WAR file name that >> converts to a "*" in the context-path? Or you want a character in a >> war:// URL that can be used as the barrier between the physical filename >> and the logical file within the WAR file? If the latter, what's wrong >> with the jar:// usage of "!/" ? > > We need to be able to reference resources in JARs in WARs. Experience > has shown that nest jar URLs don't work. We needed a dedicated war URL > format. We currently use: > war://...*/... > > We previously used > war://...^/... > > The former has issues in some use cases. The latter results in invalid URLs. > >> We are already using # for / and IMO that can be buggy since # has >> meaning in URLs. What about using an escape-character instead of a stand-in? > > It has to be a character that Java will expect in a URL.
1. The original bug report was about some embedding of Tomcat. Maybe it will be enough to make the value configurable? 2. Are we limited to US-ASCII? (If it were unicode, there are a lot of funny characters to choose from.) I see that these URLs can be used in catalina.policy (there is an example there), so it looks that we are limited. 3. We can use a delimiter that is longer than 2 characters. We are not limited to "char + '/'". 4. If the file part must refer an existing file, we can look for ".war/" incrementally and check whether it is an existing file. Though depending on how this is implemented it this may lead to false positives on Windows because of case-insensivity. (I remember how years ago I observed collision of "manager" package vs "Manager" class in isPackage() check during compilation of JSPs, trying to run Tomcat as compiled by Eclipse (as a set of classes, not packed into .jars) https://bz.apache.org/bugzilla/show_bug.cgi?id=47323 ) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
