[Bug 62641] libtool invocations should use --tag=CC
https://bz.apache.org/bugzilla/show_bug.cgi?id=62641 Michael Osipov <1983-01...@gmx.net> changed: What|Removed |Added Depends on||62640 Referenced Bugs: https://bz.apache.org/bugzilla/show_bug.cgi?id=62640 [Bug 62640] libtool invocations should use --tag=CC -- 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
svn commit: r1838527 - in /tomcat/native/trunk: native/Makefile.in xdocs/miscellaneous/changelog.xml
Author: michaelo Date: Tue Aug 21 08:16:42 2018 New Revision: 1838527 URL: http://svn.apache.org/viewvc?rev=1838527&view=rev Log: BZ-62641: libbtool invocations should use --tag=CC When using the provided libtool from APR on a different platform/compiler libtool does not properly link against libapr. Passing an external one it complains about the missing tag because a proper configuration for the current one isn't present and cannot be derived. Always pass '--tag=CC' for maximum portability. Modified: tomcat/native/trunk/native/Makefile.in tomcat/native/trunk/xdocs/miscellaneous/changelog.xml Modified: tomcat/native/trunk/native/Makefile.in URL: http://svn.apache.org/viewvc/tomcat/native/trunk/native/Makefile.in?rev=1838527&r1=1838526&r2=1838527&view=diff == --- tomcat/native/trunk/native/Makefile.in (original) +++ tomcat/native/trunk/native/Makefile.in Tue Aug 21 08:16:42 2018 @@ -57,7 +57,7 @@ ifneq ($(LIBTOOL_OLD),$(LIBTOOL)) LIBTOOL=$(LIBTOOL_OLD) endif -LINK = $(LIBTOOL) $(LTFLAGS) --mode=link $(LT_LDFLAGS) $(COMPILE) -version-info $(TCNATIVE_LIBTOOL_VERSION) $(ALL_LDFLAGS) -o $@ +LINK = $(LIBTOOL) $(LTFLAGS) --mode=link --tag=CC $(LT_LDFLAGS) $(COMPILE) -version-info $(TCNATIVE_LIBTOOL_VERSION) $(ALL_LDFLAGS) -o $@ CLEAN_SUBDIRS = test CLEAN_TARGETS = .make.dirs Modified: tomcat/native/trunk/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/native/trunk/xdocs/miscellaneous/changelog.xml?rev=1838527&r1=1838526&r2=1838527&view=diff == --- tomcat/native/trunk/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/native/trunk/xdocs/miscellaneous/changelog.xml Tue Aug 21 08:16:42 2018 @@ -34,6 +34,13 @@ This is the Changelog for Tomcat Native 1.2. + + + + 62641: libtool invocations should use --tag=CC. (michaelo) + + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62641] libtool invocations should use --tag=CC
https://bz.apache.org/bugzilla/show_bug.cgi?id=62641 Michael Osipov <1983-01...@gmx.net> changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Osipov <1983-01...@gmx.net> --- Fixed with r1838527 for 1.2.18 and newer. -- 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 62169] Not able to compile mod_jk on MacOS
https://bz.apache.org/bugzilla/show_bug.cgi?id=62169 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mark Thomas --- Resolving as INVALID based on the the previous two comments as the bug appears to be in a different tool rather than in mod_jk. -- 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
JK release
Hi all, It is getting on for 6 months since the last JK release so I am planning on making a sweep of the open bugs, fixing what I can, tagging and calling a release vote. I'm hoping to be able to tag by the end of the week but, as always, circumstances may mean that that timescale slips. There are quite a few open issues and enhancements and I very much doubt I'll be able to get to all of them so if any C coders have some spare cycles to help out that would be great (no JK experience necessary - the dev@ list can provide pointers to get you started if needed). Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: JK release
Hi Mark, at minimum I should be able review and test. Thanks Martin On Tue, Aug 21, 2018 at 11:42 AM Mark Thomas wrote: > Hi all, > > It is getting on for 6 months since the last JK release so I am planning > on making a sweep of the open bugs, fixing what I can, tagging and > calling a release vote. > > I'm hoping to be able to tag by the end of the week but, as always, > circumstances may mean that that timescale slips. > > There are quite a few open issues and enhancements and I very much doubt > I'll be able to get to all of them so if any C coders have some spare > cycles to help out that would be great (no JK experience necessary - the > dev@ list can provide pointers to get you started if needed). > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- -- Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
[Bug 60745] False positive: Somebody try to hack into the site!!!
https://bz.apache.org/bugzilla/show_bug.cgi?id=60745 --- Comment #1 from Mark Thomas --- I can confirm that the false positive is still present however I can't recreate the issue of the user being blocked until the filter is reloaded. -- 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
Removing check for WEB-INF and META-INF from JK ISAPI redirector
Hi, I've been looking into [1] which is - essentially - that a request for http:///examples/servlets/servlet/RequestInfoExample/WEB-INF will fail when it should be allowed. Currently the JK ISAPI redirector rejects any request with a path segment that is WEB-INF or META-INF irrespective of case. I'd like to propose removing this check. My reasons are: - It is unnecessary. Tomcat will reject all attempts to directly access the contents of WEB-INF or META-INF - It triggers false positives as IIS can't tell which part of a URI is the context path. For example, "/foo/bar/META-INF" is legal in the ROOT context but illegal if the context path is /foo/bar - No such restriction exists for httpd (there is a restriction when JkAutoAlias is used but that looks correct to me) Mark [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60745 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Removing check for WEB-INF and META-INF from JK ISAPI redirector
Am 21.08.2018 um 14:05 schrieb Mark Thomas: Hi, I've been looking into [1] which is - essentially - that a request for http:///examples/servlets/servlet/RequestInfoExample/WEB-INF will fail when it should be allowed. Currently the JK ISAPI redirector rejects any request with a path segment that is WEB-INF or META-INF irrespective of case. I'd like to propose removing this check. My reasons are: - It is unnecessary. Tomcat will reject all attempts to directly access the contents of WEB-INF or META-INF - It triggers false positives as IIS can't tell which part of a URI is the context path. For example, "/foo/bar/META-INF" is legal in the ROOT context but illegal if the context path is /foo/bar - No such restriction exists for httpd (there is a restriction when JkAutoAlias is used but that looks correct to me) Mark [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=60745 Not knowing enough about IIS, the check is old (at least version 1.2.0 and also existed in jk2. In jk2 there was a comment "XXX Make it a default checking in uri worker map" indicating, that it was originally meant to be used not only for IIS. All in all I agree, that the check must exist in the AJP back end (such as Tomcat). I don't know, how e.g. Jetty behaves but since mod_jk doesn't have the check either, I do not expect a problem removing it (and documenting the removal). Thanks for raising this, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1838548 - /tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
Author: markt
Date: Tue Aug 21 14:05:11 2018
New Revision: 1838548
URL: http://svn.apache.org/viewvc?rev=1838548&view=rev
Log:
Trivial format fixes
Modified:
tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
Modified: tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java?rev=1838548&r1=1838547&r2=1838548&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/http/MimeHeaders.java Tue Aug 21
14:05:11 2018
@@ -286,7 +286,7 @@ public class MimeHeaders {
* @return the message bytes container for the value
*/
public MessageBytes addValue( String name ) {
- MimeHeaderField mh = createHeader();
+MimeHeaderField mh = createHeader();
mh.getName().setString(name);
return mh.getValue();
}
@@ -300,8 +300,7 @@ public class MimeHeaders {
* @param len Length
* @return the message bytes container for the value
*/
-public MessageBytes addValue(byte b[], int startN, int len)
-{
+public MessageBytes addValue(byte b[], int startN, int len) {
MimeHeaderField mhf=createHeader();
mhf.getName().setBytes(b, startN, len);
return mhf.getValue();
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #15 from Christopher Schultz --- (In reply to jan.pfeifer from comment #13) > (In reply to Christopher Schultz from comment #12) > > > Just to confirm: this is Java 8 with APR+OpenSSL, not NIO+OpenSSL, correct? > > Yes, actual configuration APR+OpenSSL Java 8. Three days without crash. That's good to hear. It's surprising, but at least you have a configuration you can fall-back to if you don't want crashes. -- 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
svn commit: r1838553 - in /tomcat/jk/trunk: native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Author: markt
Date: Tue Aug 21 14:39:03 2018
New Revision: 1838553
URL: http://svn.apache.org/viewvc?rev=1838553&view=rev
Log:
ISAPI: Remove the check that rejects requests that contain path segments that
match WEB-INF or META-INF as it duplicates a check that Tomcat performs and,
because ISAPI does not have visibility of the current context path, it is
impossible to implement this check without valid requests being rejected
Modified:
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=1838553&r1=1838552&r2=1838553&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Tue Aug 21 14:39:03 2018
@@ -874,36 +874,6 @@ static char *stristr(const char *s, cons
return ((char *)s);
}
-/*
- * Find the first occurrence of path in uri tokenized by "/".
- * The comparison is done case insensitive.
- */
-static const char *find_path_in_uri(const char *uri, const char *path)
-{
-size_t len = strlen(path);
-while (uri = strchr(uri, '/')) {
-uri++;
-if (!strnicmp(uri, path, len) &&
-(*(uri + len) == '/' ||
- strlen(uri) == len)) {
-return uri;
-}
-}
-return NULL;
-}
-
-static int uri_is_web_inf(const char *uri)
-{
-if (find_path_in_uri(uri, "web-inf")) {
-return JK_TRUE;
-}
-if (find_path_in_uri(uri, "meta-inf")) {
-return JK_TRUE;
-}
-
-return JK_FALSE;
-}
-
static void write_error_response(PHTTP_FILTER_CONTEXT pfc, int err)
{
char status[1024];
@@ -1930,22 +1900,6 @@ static DWORD handle_notify_event(PHTTP_F
isapi_log_data_t *ld;
BOOL rs;
-if (JK_IS_DEBUG_LEVEL(logger))
-jk_log(logger, JK_LOG_DEBUG,
- "check if [%s] points to the web-inf directory",
-uri);
-
-if (uri_is_web_inf(uri)) {
-jk_log(logger, JK_LOG_EMERG,
- "[%s] points to the web-inf or meta-inf directory. "
- "Somebody tries to hack into the site!!!",
- uri);
-
-write_error_response(pfc, 404);
-rv = SF_STATUS_REQ_FINISHED;
-goto cleanup;
-}
-
/* This is a servlet, should redirect ... */
if (JK_IS_DEBUG_LEVEL(logger))
jk_log(logger, JK_LOG_DEBUG,
Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1838553&r1=1838552&r2=1838553&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Aug 21 14:39:03 2018
@@ -49,6 +49,13 @@
since there has not been a supported version of Netware available for
over five years. (markt)
+
+60745: ISAPI: Remove the check that rejects requests that
+contain path segments that match WEB-INF or META-INF as it duplicates
+a check that Tomcat performs and, because ISAPI does not have
visibility
+of the current context path, it is impossible to implement this check
+without valid requests being rejected. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 60745] False positive: Somebody try to hack into the site!!!
https://bz.apache.org/bugzilla/show_bug.cgi?id=60745 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Thomas --- This has been fixed in 1.2.x for 1.2.44 onwards. The check has essentially been removed from the ISAPI code as a) Tomcat performs the check any way and b) ISAPI can't perform the check correctly without knowledge of the current context path which it does not have. -- 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
Re: JK release
On 8/21/2018 2:42 AM, Mark Thomas wrote: Hi all, It is getting on for 6 months since the last JK release so I am planning on making a sweep of the open bugs, fixing what I can, tagging and calling a release vote. I'm hoping to be able to tag by the end of the week but, as always, circumstances may mean that that timescale slips. There are quite a few open issues and enhancements and I very much doubt I'll be able to get to all of them so if any C coders have some spare cycles to help out that would be great (no JK experience necessary - the dev@ list can provide pointers to get you started if needed). I'd be happy to help with these. Please provide pointers to get started. Thanks, Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62626] Tomcat 9.0.10 APR/Native crashes
https://bz.apache.org/bugzilla/show_bug.cgi?id=62626 --- Comment #16 from Christopher Schultz --- (In reply to jan.pfeifer from comment #13) > Two last Thread reports: > > --- T H R E A D --- > > Current thread (0x2f30d800): JavaThread > "https-openssl-apr-443-exec-69" daemon [_thread_in_native, id=36360, > stack(0x3f5e,0x3f6e)] > > Stack: [0x3f5e,0x3f6e], sp=0x3f6ddd80, > free space=1015k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [tcnative-1.dll+0xe0a8f] > No more information about the native frame. That must be a direct-native call... > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > J 10218 org.apache.tomcat.jni.Socket.sendb(JLjava/nio/ByteBuffer;II)I (0 > bytes) @ 0x14d3c59f [0x14d3c540+0x005f] > J 15904 c2 org.apache.tomcat.util.net.SocketWrapperBase.flushBlocking()V (90 > bytes) @ 0x1545cbcc [0x1545c880+0x034c] > J 16170 c2 org.apache.tomcat.util.net.SocketWrapperBase.flush(Z)Z (20 bytes) > @ 0x14860a78 [0x14860a40+0x0038] > J 15983 c2 org.apache.catalina.connector.CoyoteOutputStream.write([BII)V (26 > bytes) @ 0x154a8f2c [0x154a51c0+0x3d6c] > J 16090 c2 java.io.BufferedOutputStream.write([BII)V java.base@10.0.2 (67 > bytes) @ 0x154e5660 [0x154e5560+0x0100] > J 18370 c2 > com.m2000.shop.controllers.DefaultController.image(Ljava/lang/String;Ljava/ > lang/String;Ljava/lang/String;Ljavax/servlet/http/HttpServletResponse;Ljavax/ > servlet/http/HttpServletRequest;)V (1129 bytes) @ 0x159f12f4 > [0x159ec920+0x49d4] Okay, this is good information: 1. The crash is occurring in jni.Socket.sendbb (where many crashes have historically been found) 2. Your code is intentionally invoking a write() on the socket/stream That means that we can take a look at your code to see if there is any misuse of the streams. That is the #1 reason for crashes like these: the application misuses a stream (e.g. after it should have been recycled) and it's in an intermediate state. tcnative should not crash, but we may be able to mitigate it by fixing your code. Can you post as much of your code as possible? Feel free to do so privately if you don't want your code published in BZ. > J 19092 c2 > jdk.internal.reflect.GeneratedMethodAccessor159.invoke(Ljava/lang/Object; > [Ljava/lang/Object;)Ljava/lang/Object; (98 bytes) @ 0x15ba9be8 > [0x15ba9b00+0x00e8] > J 19001 c2 > org.springframework.web.method.support.InvocableHandlerMethod. > invokeForRequest(Lorg/springframework/web/context/request/NativeWebRequest; > Lorg/springframework/web/method/support/ModelAndViewContainer;[Ljava/lang/ > Object;)Ljava/lang/Object; (148 bytes) @ 0x15b26018 > [0x15b25ca0+0x0378] Coming through Spring. > J 18530 c2 > org.springframework.web.servlet.mvc.method.annotation. > ServletInvocableHandlerMethod.invokeAndHandle(Lorg/springframework/web/ > context/request/ServletWebRequest;Lorg/springframework/web/method/support/ > ModelAndViewContainer;[Ljava/lang/Object;)V (142 bytes) @ 0x15a6e884 > [0x15a6e840+0x0044] > J 18568 c2 > org.springframework.web.servlet.mvc.method.annotation. > RequestMappingHandlerAdapter.invokeHandlerMethod(Ljavax/servlet/http/ > HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Lorg/ > springframework/web/method/HandlerMethod;)Lorg/springframework/web/servlet/ > ModelAndView; (328 bytes) @ 0x15a92a48 > [0x15a90d60+0x1ce8] > J 19592 c2 > org.springframework.web.servlet.DispatcherServlet.doDispatch(Ljavax/servlet/ > http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (594 > bytes) @ 0x15ca8c20 [0x15ca8140+0x0ae0] > J 18099 c2 > org.springframework.web.servlet.DispatcherServlet.doService(Ljavax/servlet/ > http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (360 > bytes) @ 0x15948490 [0x15947ee0+0x05b0] > J 18074 c2 > org.springframework.web.servlet.FrameworkServlet.processRequest(Ljavax/ > servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V > (298 bytes) @ 0x15919044 [0x159171c0+0x1e84] > J 19591 c2 > javax.servlet.http.HttpServlet.service(Ljavax/servlet/http/ > HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V (269 bytes) @ > 0x15ca6d70 [0x15ca6bc0+0x01b0] >From normal Tomcat dispatch. Great. At least there is no odd threading or anything going on, here. That makes it less likely to be a problem in your code. > siginfo: EXCEPTION_ACCESS_VIOLATION (0xc005), writing address > 0x01a0 Interesting. Most of the crashes in the past have been when reading data, not writing it. Therefore, most of
Re: JK release
On 8/21/2018 8:54 AM, Igal Sapir wrote: On 8/21/2018 2:42 AM, Mark Thomas wrote: There are quite a few open issues and enhancements and I very much doubt I'll be able to get to all of them so if any C coders have some spare cycles to help out that would be great (no JK experience necessary - the dev@ list can provide pointers to get you started if needed). I'd be happy to help with these. Please provide pointers to get started. I'm sorry. I just realized that "C Coders" was not a typo. I thought it was a task for a Java coder. Please ignore my previous message. Igal - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54117] access violation exception in isapi_redirect.dll
https://bz.apache.org/bugzilla/show_bug.cgi?id=54117 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #17 from Mark Thomas --- I been spending some time looking into this. It appears that the problem was triggered by some invalid request headers being passed to ISAPI. I have been unable to recreate this on Windows 2008 or 2016. My conclusion, therefore, is that somewhere between 2012 and now, IIS tightened up its header parsing. I am therefore resolving this bug as WORKSFORME. If anyone is still experiencing this issue with: - a fully patched, currently supported version of Windows; and - the latest JK 1.2.x release then please feel free to re-open this issue and provide the steps to reproduce. -- 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
svn commit: r1838569 - /tomcat/jk/trunk/native/common/jk_connect.c
Author: markt
Date: Tue Aug 21 16:35:43 2018
New Revision: 1838569
URL: http://svn.apache.org/viewvc?rev=1838569&view=rev
Log:
Fix typo
Modified:
tomcat/jk/trunk/native/common/jk_connect.c
Modified: tomcat/jk/trunk/native/common/jk_connect.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_connect.c?rev=1838569&r1=1838568&r2=1838569&view=diff
==
--- tomcat/jk/trunk/native/common/jk_connect.c (original)
+++ tomcat/jk/trunk/native/common/jk_connect.c Tue Aug 21 16:35:43 2018
@@ -427,7 +427,7 @@ int jk_resolve(const char *host, int por
#if JK_HAVE_IPV6
if (strchr(host, ':')) {
-/* If host name contains collon this must be IPV6 address.
+/* If host name contains colon this must be IPV6 address.
* Set prefer_ipv6 flag in this case if it wasn't set already
*/
prefer_ipv6 = 1;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54027] isapi send request to outside address instead of internal address if server is in NAT
https://bz.apache.org/bugzilla/show_bug.cgi?id=54027 Mark Thomas changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #5 from Mark Thomas --- If the host name configured in the workers.properties does not resolve as intended then that is a DNS / workers.properties configuration issue. -- 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
svn commit: r1838573 - in /tomcat/jk/trunk: native/common/jk_shm.c native/iis/jk_isapi_plugin.c xdocs/miscellaneous/changelog.xml
Author: markt
Date: Tue Aug 21 17:39:32 2018
New Revision: 1838573
URL: http://svn.apache.org/viewvc?rev=1838573&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58287
Common: Use Local, rather than Global, mutexs on Windows to better support
multi-user environments.
Modified:
tomcat/jk/trunk/native/common/jk_shm.c
tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
Modified: tomcat/jk/trunk/native/common/jk_shm.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/common/jk_shm.c?rev=1838573&r1=1838572&r2=1838573&view=diff
==
--- tomcat/jk/trunk/native/common/jk_shm.c (original)
+++ tomcat/jk/trunk/native/common/jk_shm.c Tue Aug 21 17:39:32 2018
@@ -223,7 +223,7 @@ int jk_shm_open(const char *fname, int s
if (fname) {
int i;
SIZE_T shmsz = 0;
-strcpy(shname, "Global\\");
+strcpy(shname, "Local\\");
strncat(shname, fname, MAX_PATH - 8);
for(i = 7; i < (int)strlen(shname); i++) {
if (!jk_isalnum(shname[i]))
Modified: tomcat/jk/trunk/native/iis/jk_isapi_plugin.c
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/iis/jk_isapi_plugin.c?rev=1838573&r1=1838572&r2=1838573&view=diff
==
--- tomcat/jk/trunk/native/iis/jk_isapi_plugin.c (original)
+++ tomcat/jk/trunk/native/iis/jk_isapi_plugin.c Tue Aug 21 17:39:32 2018
@@ -2341,7 +2341,7 @@ BOOL WINAPI DllMain(HINSTANCE hInst,
*p = '\0';
StringCbCopy(ini_file_name, MAX_PATH, fname);
StringCbCat(ini_file_name, MAX_PATH, ".properties");
-StringCbCopy(ini_mutex_name, MAX_PATH, "Global\\JK_");
+StringCbCopy(ini_mutex_name, MAX_PATH, "Local\\JK_");
StringCbCat(ini_mutex_name, MAX_PATH, fname);
StringCbCat(ini_mutex_name, MAX_PATH, "_mutex");
p = &ini_mutex_name[10];
Modified: tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml?rev=1838573&r1=1838572&r2=1838573&view=diff
==
--- tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/jk/trunk/xdocs/miscellaneous/changelog.xml Tue Aug 21 17:39:32 2018
@@ -50,6 +50,10 @@
over five years. (markt)
+58287: Common: Use Local, rather than Global, mutexs on
+Windows to better support multi-user environments. (markt)
+
+
60745: ISAPI: Remove the check that rejects requests that
contain path segments that match WEB-INF or META-INF as it duplicates
a check that Tomcat performs and, because ISAPI does not have
visibility
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 58287] Questionable use of "Global" objects on Windows
https://bz.apache.org/bugzilla/show_bug.cgi?id=58287 Mark Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Mark Thomas --- I've been doing some research: https://docs.microsoft.com/en-gb/windows/desktop/TermServ/kernel-object-namespaces Global essentially means all user sessions (including the system). Local means the current session. Local looks like the better choice to me. As a sanity check, I've changed it in my local build with no obvious issues with ISAPI. Fixed in 1.2.x for 1.2.44 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #3 from Mark Thomas --- Can you please provide an example of a URI presented by a client that demonstrates this issue. -- 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 62459] mod_jk: Forwarding URLs containing escaped slashes (e.g. for REST services) fail with syntactical-wrong double-escaping
https://bz.apache.org/bugzilla/show_bug.cgi?id=62459 --- Comment #4 from Guido Jäkel --- (In reply to Mark Thomas from comment #3) > Can you please provide an example of a URI presented by a client that > demonstrates this issue. Dear Mark, A real world example is http://nbn-resolving.org/urn:nbn:de:gbv:7-11858%2F00-1735--0001-B8C0-F-4 , it will answer with a redirect to http://ediss.uni-goettingen.de/handle/11858/00-1735--0001-B8C0-F Without the patch, this will forwarded as /urn:nbn:de:gbv:7-11858%252F00-1735--0001-B8C0-F-4 This example is taken from real production which uses "JkOptions +ForwardURICompatUnparsed" at the moment as a workaround. But with the suggested patch (as proved in our test stage), one may use "+ForwardURIProxy", again. In addition, you have to use "AllowEncodedSlashes NoDecode" in the corresponding VHost, too. I was not able to use this as a global option, this seems to be another issue. -- 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
