[Bug 57402] New: Provide correlation ID between mod_jk log and access log
https://issues.apache.org/bugzilla/show_bug.cgi?id=57402 Bug ID: 57402 Summary: Provide correlation ID between mod_jk log and access log Product: Tomcat Connectors Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: mod_jk Assignee: dev@tomcat.apache.org Reporter: rainer.j...@kippdata.de Since version 2.4 of the Apache web server it has a feature named correlation ID, that allows to log a unique id in the error log and the access log. If you want to identify a request which triggered an error message, you can pick the correlation id from the error message and look for the same id in the access log. The id will be unique per request. Furthermore for cases where the error occured before reading the request, there is also a connection correlation id. The IDs are in the log_id member of the requets and connection structs. It would be nice if mod_jk would also add the ID to its mod_jk log. There are several implementation problems though: - mod_jk doesn't pass a request or connection struct down to the log implementation. So we can't easily access log_id. It might be possible by introducing thread local storage - which is supported by many platforms - and set a TLS pointer to the connection and request objects early during processing. - Apache sets the log_id not for every request, but only when it needs to write an error message for a request. We could set the log_id fields in mod_jk though (if not already set). It seems Apache won't overwrite them if they are already set (needs checking, see add_log_id() in server/log.c). - Making this work for Apache before 2.4 must be based on a different storage location for the log_id. - I haven't thought about making this even work for ISAPI. I currently don't plan working on this. Patches welcome. -- 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 57403] New: Persist configuration changes made via status worker
https://issues.apache.org/bugzilla/show_bug.cgi?id=57403 Bug ID: 57403 Summary: Persist configuration changes made via status worker Product: Tomcat Connectors Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P2 Component: Common Assignee: dev@tomcat.apache.org Reporter: rainer.j...@kippdata.de The status worker should have an optional feature to save any configuration changes made via its GUI to workers.properties. Writing a configuraiton file is typically not an easy task, because you would loose comments and other structure of the original file, e.g. property inheritance via the "reference" attribute. One implementation idea would be second "journal" file to which one would write a protocol of all new propertiy values coming our of status worker changes. Only changes with a "persist" checkbox set in the GUI would be written there. During startup mod_jk would read the original workers.properties and then overlay the journal file to reacreate the last "persisted" configuration state. A sysadmin could at any time either roll back by deleting the journal file or parts of it, or reintegrate the journal file contents into the original workers.properties. The default name of the journal file could be the value of JkWorkersFile plus some suffix, like ".journal" or ".changes". For situations, where the file has to go to some other place, a JkWorkersJounrnalFile directive could be used to explicitely set the file (and dir). The default in the status worker GUI would be not to persist, activating it via a checkbox in the forms, in which one can set new property values. A configuration item for the status worker could switch defaults (it would still show the same checkbox, but then it would be checked by default). If saving the properties fails, the status workr would show an error message and also log an error. If mod_jk finds a journal file, it would log its existence and processing on info log level during startup. The journal file could also contain a comment line for each property line, which contains a timestamp of the change and maybe user name and other meta data (client IP? User comment added via GUI?). I currently do not plan to work on this but patches are welcome. -- 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 57405] New: Don't warn about invalid URI if URI is "*"
https://issues.apache.org/bugzilla/show_bug.cgi?id=57405 Bug ID: 57405 Summary: Don't warn about invalid URI if URI is "*" Product: Tomcat Connectors Version: 1.2.40 Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: minor Priority: P2 Component: mod_jk Assignee: dev@tomcat.apache.org Reporter: ch...@christopherschultz.net >From an old complaint that is still plaguing us 4 years later: http://markmail.org/thread/o3iiojm427tmfssd Certain software and/or hardware probe for availability using a request like this: OPTIONS * HTTP/1.1 When mod_jk checks to see if this is a URI to handle, it complains with a WARN-level message in mod_jk.log: [Tue Dec 30 14:33:27.141 2014] [17353:140224749586432] [warn] map_uri_to_worker_ext::jk_uri_worker_map.c (1096): Uri * is invalid. Uri must start with / Since this is a) A valid URI / request b) Not one to be handled by mod_jk therefore mod_jk should not complain. As a corollary, it ought to be possible to "JkMount *" or something similar so that "OPTIONS *" requests can be forwarded to Tomcat explicitly. -- 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 57403] Persist configuration changes made via status worker
https://issues.apache.org/bugzilla/show_bug.cgi?id=57403 --- Comment #1 from Christopher Schultz --- Please make the persistability something that needs to be explicitly enabled for the module. We don't need an accidental security hole added for users who don't ever want to use the feature. -- 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 57405] Don't warn about invalid URI if URI is "*"
https://issues.apache.org/bugzilla/show_bug.cgi?id=57405 Rainer Jung changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Rainer Jung --- The warning was toned down to a debug message in this case. Being able to forward an "OPTIONS *" would be a separate enhancement request. Not sure how to implement that (because mounts currently don't check http method). *** This bug has been marked as a duplicate of bug 50511 *** -- 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 50511] WARNING about Internal Dummy Connection of Apache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50511 Rainer Jung changed: What|Removed |Added CC||ch...@christopherschultz.ne ||t --- Comment #9 from Rainer Jung --- *** Bug 57405 has been marked as a duplicate of this bug. *** -- 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 50511] WARNING about Internal Dummy Connection of Apache
https://issues.apache.org/bugzilla/show_bug.cgi?id=50511 --- Comment #10 from Christopher Schultz --- (In reply to Rainer Jung from comment #9) > *** Bug 57405 has been marked as a duplicate of this bug. *** Thanks for finding this... I was positive it was in BZ somewhere but couldn't find it because it was a) filed using different description and b) already fixed but c) not yet released. -- 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: r1648541 - /tomcat/jk/trunk/native/buildconf.sh
Author: schultz
Date: Tue Dec 30 15:34:43 2014
New Revision: 1648541
URL: http://svn.apache.org/r1648541
Log:
Allow libtoolize command to be specified via LIBTOOLIZE environment variable.
Modified:
tomcat/jk/trunk/native/buildconf.sh
Modified: tomcat/jk/trunk/native/buildconf.sh
URL:
http://svn.apache.org/viewvc/tomcat/jk/trunk/native/buildconf.sh?rev=1648541&r1=1648540&r2=1648541&view=diff
==
--- tomcat/jk/trunk/native/buildconf.sh (original)
+++ tomcat/jk/trunk/native/buildconf.sh Tue Dec 30 15:34:43 2014
@@ -18,8 +18,8 @@
scripts/build/unix/buildcheck.sh || exit 1
rm -rf autom4te.cache 2>/dev/null || true
-echo "buildconf: libtoolize --automake --copy"
-libtoolize --automake --copy
+echo "buildconf: ${LIBTOOLIZE:-libtoolize} --automake --copy"
+${LIBTOOLIZE:-libtoolize} --automake --copy
echo "buildconf: aclocal"
#aclocal --acdir=`aclocal --print-ac-dir`
#aclocal --acdir=/usr/local/share/aclocal
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56618] Can not set Hostname property to IPv6 address using JK Status Manager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56618 --- Comment #2 from Christopher Schultz --- (In reply to Konstantin Kolinko from comment #1) > Looking at the code, jk_status.c has its own HTTP query parameters parsing > (status_parse_uri() in native/common/jk_status.c), implemented by splitting > the query string. > The url-decoding of parameters is not performed. There is a comment that it > had been planned, but has not been implemented yet. > > /* XXX Depending on the params values, we might need to trim and decode */ Yes, jk_status.c:1277 looks like the right place to do this. It seems no parameter-decoding is happening at all, probably because mod_jk never expects to get a parameter value that is encoded in any way. There are several settings that could be affected in this way: hostname, route, redirect-route, cluster-domain, worker-name The last one (worker-name) could be configured properly in workers.properties, but then be unable to send the worker's name via HTTP without encoding, in which case mod_jk would never be able to find the worker. -- 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 56618] Can not set Hostname property to IPv6 address using JK Status Manager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56618 --- Comment #3 from Christopher Schultz --- Created attachment 32339 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32339&action=edit Initial patch with (possibly) sloppy memory management I have a patch which lifts the whole apr_unescape_url method from APR 1.5 and uses it in jk_status:status_parse_uri and initial testing suggests that it works. However, I have been lazy with my memory allocations because I have not yet understood how jk_map_put deals with memory. I'm attaching my proposed patch with the understanding that it is almost certainly not complete, as it likely contains a memory leak. It also does not decode parameter *names*, but it doesn't seem like the mod_jk status worker really needs that right 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
[Bug 56618] Can not set Hostname property to IPv6 address using JK Status Manager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56618 Christopher Schultz changed: What|Removed |Added Attachment #32339|0 |1 is obsolete|| --- Comment #4 from Christopher Schultz --- Created attachment 32340 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32340&action=edit A better patch without memory leaks -- 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 56618] Can not set Hostname property to IPv6 address using JK Status Manager
https://issues.apache.org/bugzilla/show_bug.cgi?id=56618 Christopher Schultz changed: What|Removed |Added Attachment #32339|0 |1 is patch|| -- 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: r1648589 - /tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
Author: schultz Date: Tue Dec 30 19:58:08 2014 New Revision: 1648589 URL: http://svn.apache.org/r1648589 Log: Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48460 - Clarified staggeringly incorrect statement about byte-order - Fixed bad hex mental math - Unwound logical confusion about true versus false values and their meanings Modified: tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml Modified: tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml?rev=1648589&r1=1648588&r2=1648589&view=diff == --- tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml (original) +++ tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml Tue Dec 30 19:58:08 2014 @@ -145,13 +145,11 @@ Response Packet Structures below for det There is a bit of an XDR heritage to this protocol, but it differs in lots of ways (no 4 byte alignment, for example). - -Byte order: I am not clear about the endian-ness of the individual -bytes. I'm guessing the bytes are little-endian, because that's what XDR -specifies, and I'm guessing that sys/socket library is magically making -that so (on the C side). If anyone with a better knowledge of socket calls -can step in, that would be great. - + + + AJP13 uses network byte order for all data types. + + There are four data types in the protocol: bytes, booleans, integers and strings. @@ -489,7 +487,7 @@ additional methods, even if they are not two-byte integer is the length of a string, which is then read in. This works on the assumption that no header names will have length - greater than 0x (==0xA000 - 1), which is perfectly reasonable, though + greater than 0x9FFF (==0xA000 - 1), which is perfectly reasonable, though somewhat arbitrary. (If you, like me, started to think about the cookie spec here, and about how long headers can get, fear not -- this limit is on header names not header values. It seems unlikely that @@ -509,7 +507,7 @@ additional methods, even if they are not The attributes prefixed with a ? (e.g. ?context) are all optional. For each, there is a single byte code to indicate the type of attribute, and then a string to - give its value. They can be sent in any order (thogh the C code always + give its value. They can be sent in any order (though the C code always sends them in the order listed below). A special terminating code is sent to signal the end of the list of optional attributes. The list of byte codes is: @@ -654,8 +652,8 @@ Details: Signals the end of this request-handling cycle. If the reuse flag is true (==1), this TCP connection can now be used to - handle new incoming requests. If reuse is false (anything - other than 1 in the actual C code), the connection should be closed. + handle new incoming requests. If reuse is true (anything + other than 0 in the actual C code), the connection should be closed. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 48460] mod_proxy_ajp document has three misleading portions
https://issues.apache.org/bugzilla/show_bug.cgi?id=48460 Christopher Schultz changed: What|Removed |Added Component|Documentation |Documentation Version|1.2.0 |2.0-HEAD Assignee|dev@tomcat.apache.org |d...@httpd.apache.org Product|Tomcat Connectors |Apache httpd-2 --- Comment #2 from Christopher Schultz --- Fixed the original (mod_jk) documentation in r1648589. Assigning to httpd-docs to get mod_proxy_ajp documentation 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 54621] [PATCH] custom mod_jk availability checks
https://issues.apache.org/bugzilla/show_bug.cgi?id=54621 Christopher Schultz changed: What|Removed |Added Attachment #30004|0 |1 is patch|| Attachment #30004|application/octet-stream|text/plain mime type|| -- 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
[GUMP@vmgump]: Project tomcat-native-make (in module tomcat-native) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project tomcat-native-make has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 48 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - tomcat-native-make : Tomcat native library using Apache Portable Runtime - tomcat-native-make-install : Tomcat native library using Apache Portable Runtime Full details are available at: http://vmgump.apache.org/gump/public/tomcat-native/tomcat-native-make/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/tomcat-native/tomcat-native-make/gump_work/build_tomcat-native_tomcat-native-make.html Work Name: build_tomcat-native_tomcat-native-make (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: make [Working Directory: /srv/gump/public/workspace/tomcat-native/native] - make[1]: Entering directory `/srv/gump/public/workspace/tomcat-native/native' /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/address.lo -c src/address.c && touch src/address.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/bb.lo -c src/bb.c && touch src/bb.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/dir.lo -c src/dir.c && touch src/dir.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/error.lo -c src/error.c && touch src/error.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/file.lo -c src/file.c && touch src/file.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace/apr-1/dest-20141231/include/apr-1 -o src/info.lo -c src/info.c && touch src/info.lo /bin/bash /srv/gump/public/workspace/apr-1/dest-20141231/build-1/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX -D_REENTRANT -D_GNU_SOURCE -g -O2 -DHAVE_OPENSSL -I/srv/gump/public/workspace/tomcat-native/native/include -I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux -I/srv/gump/public/workspace/openssl/dest-20141231/include -I/srv/gump/public/workspace
