[Bug 66370] AccessControlException and default behavior change with org.apache.el.GET_CLASSLOADER_USE_PRIVILEGED
https://bz.apache.org/bugzilla/show_bug.cgi?id=66370 --- Comment #8 from Mark Thomas --- That is a fair point that the necessary privilege blocks should be in place inside the EL. If the default for the GET_CLASSLOADER_USE_PRIVILEGED system property was changed, and the code that obtained the value for that system property was obtained inside a privilege block, would that address the issues Open Liberty is seeing? I ask as I might have a (less ugly than my previous ideas) way to have a different default depending on whether or not the code is running on Tomcat which would also address the performance concerns. -- 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 66392] New: AccessLogValue's file encoding does not correspond to the documentation
https://bz.apache.org/bugzilla/show_bug.cgi?id=66392
Bug ID: 66392
Summary: AccessLogValue's file encoding does not correspond to
the documentation
Product: Tomcat 8
Version: 8.5.84
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: micha...@apache.org
Target Milestone:
This [1] resource says:
encoding: Character set used to write the log file. An empty string means to
use the system default character set. Default value: use the system default
character set.
But the code [2] does ISO-8859-1:
> if (encoding != null) {
> try {
> charset = B2CConverter.getCharset(encoding);
> } catch (UnsupportedEncodingException ex) {
> log.error(sm.getString(
> "accessLogValve.unsupportedEncoding", encoding), ex);
> }
> }
> if (charset == null) {
> charset = StandardCharsets.ISO_8859_1;
> }
May java.nio.charset.Charset.defaultCharset() would be better here, no?
Note: I haven't verified with other Tomcat versions, but I guess they have the
same problem.
[1]
https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve/Attributes
[2]
https://github.com/apache/tomcat/blob/cf2015c1350a3f057182dd4c26c20f68df8b3400/java/org/apache/catalina/valves/AccessLogValve.java#L638-L648
--
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 66392] AccessLogValue's file encoding does not correspond to the documentation
https://bz.apache.org/bugzilla/show_bug.cgi?id=66392 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- 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 66393] New: ExtendedAccessLogValve's x-P(XXX) does not correspond to the documentation
https://bz.apache.org/bugzilla/show_bug.cgi?id=66393
Bug ID: 66393
Summary: ExtendedAccessLogValve's x-P(XXX) does not correspond
to the documentation
Product: Tomcat 8
Version: 8.5.84
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: micha...@apache.org
Target Milestone:
This [1] resource says:
x-P(XXX) for the URL encoded (using UTF-8) request parameter with name XXX
But the code [2] does:
> try {
> return URLEncoder.encode(value, "UTF-8");
> } catch (UnsupportedEncodingException e) {
> // Should never happen - all JVMs are required to support
> UTF-8
> return null;
> }
> }
This is java.net.URLEncoder. We all know that this class is deceiving because
it actually implements form encoding (Javadoc: Utility class for HTML form
encoding. This class contains static methods for converting a String to the
application/x-www-form-urlencoded MIME format.) and not URL/URI encoding which
produces different results. Tomcat includes a decent URLEcoder class, maybe
this one should rather be used, no?
Note: I haven't verified with other Tomcat versions, but I guess they have the
same problem.
[1]
https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Extended_Access_Log_Valve/Attributes
[2]
https://github.com/apache/tomcat/blob/cf2015c1350a3f057182dd4c26c20f68df8b3400/java/org/apache/catalina/valves/ExtendedAccessLogValve.java#L412-L418
--
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 66393] ExtendedAccessLogValve's x-P(XXX) does not correspond to the documentation
https://bz.apache.org/bugzilla/show_bug.cgi?id=66393 Michael Osipov changed: What|Removed |Added CC||micha...@apache.org -- 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 66370] AccessControlException and default behavior change with org.apache.el.GET_CLASSLOADER_USE_PRIVILEGED
https://bz.apache.org/bugzilla/show_bug.cgi?id=66370 --- Comment #9 from Isaac Rivera Rivas --- Yes, if the default is changed and the property lookup is wrapped in a privilege block it should fix at least the issues seen in Open Liberty. I've tested with the changes in the proposed PR https://github.com/apache/tomcat/pull/572 (not exactly changing the default but in essence reverting to the default behavior) and have seen the issues fixed. -- 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 66392] AccessLogValue's file encoding does not correspond to the documentation
https://bz.apache.org/bugzilla/show_bug.cgi?id=66392 --- Comment #1 from Han Li --- (In reply to Michael Osipov from comment #0) > May java.nio.charset.Charset.defaultCharset() would be better here, no? No, I found the reason why not use java.nio.charset.Charset.defaultCharset() by git commit log. https://github.com/apache/tomcat/commit/972212836bf278e443b87418d961d6ddb04262a6 I also have a question based on the comment at BZ51408, is it time to use UTF-8 as the default encoding set now? -- 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
