[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351 --- Comment #6 from Martin Nybo Andersen --- Thanks Mark, Both for the explanation and the quick fix. My url-mappings work again from r1803226. :-) Kind regards, Martin -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Mark Thomas --- Thanks for the report. This has been fixed in trunk (for 9.0.0.M26) and 8.5.x (for 8.5.20 onwards). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351 --- Comment #4 from Mark Thomas --- The requirement the URL patterns in web.xml must be decoded dates back to Servlet 2.3 (see r285186). -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351 --- Comment #3 from Martin Nybo Andersen --- Hi Mark, If the 'pattern is assumed to be in URL-decoded form', why decode it again? Kind regards, Martin -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351
--- Comment #2 from Konstantin Kolinko ---
Interesting analysis.
A servlet-mapping can be created by a tool. E.g. JspC:
https://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/JspC.java?revision=1800816&view=markup#l1092
o.a.j.JspC.generateWebMapping()
Encoding of generated web.xml file is configurable ("-webxmlencoding" switch),
but the pattern itself is simply written as
> mappingout.write(file.replace('\\', '/'));
If we are to require that url-mapping pattern is urlencoded, JspC should be
adjusted for that.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61351] Non-US-ASCII letters in url-mapping
https://bz.apache.org/bugzilla/show_bug.cgi?id=61351 --- Comment #1 from Mark Thomas --- The requirement the URL patterns in web.xml must be decoded dates back to Servlet 2.3 (see r285186). In more recent times this has been tweaked so the the charset used to do the decoding is consistent with the charset used for the web.xml file (see r1758423). However, the expectation from the Java EE XSD is that: This pattern is assumed to be in URL-decoded form and must not contain CR(#xD) or LF(#xA) The Servlet specification also references RFC 3986 although it doesn't offer a view on where that RFC applies and where it does not. Those do not appear to be entirely consistent. Given the above, it is also worth noting the rare edge cases where a literal '*' or '%' needs to be used in the url-pattern. So, where to go from here? My current thinking is that Tomcat needs to assume the url-patterns may be partially decoded. i.e. they may contain characters not permitted by RFC 3986 and they may also contain %nn sequences that need to be decoded. Therefore, r1793440 needs to be reverted / rewritten on that basis. I'm going to start work in this direction but if folks disagree with my analysis or think I have missed one or more important points, please do speak up. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
