On 17/01/2017 21:08, Konstantin Kolinko wrote: > 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?
That might be a solution. It is certainly worth of some further thought. > 2. Are we limited to US-ASCII? (If it were unicode, there are a lot > of funny characters to choose from.) Yes, we are limited to US-ASCII. > 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 + '/'". True. The main reason for a single character was consistency with the JAR handling. > 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. Interesting idea. The check for an existing file could be relatively expensive though. Mark > > (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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
