Re: Working on patch (need feedback)
Gross, Jessica wrote: While using Tomcat and Active Directory, I found a small bug. Normally in LDAP, you escape certain special characters, one of which being the comma. This is done by DN=CN=Doe\, Jane, OU=unit, OU=People However, when I instructed Tomcat to search for roles by inserting the distinguished name, no results were found. This is because I found in Active Directory in an object filter you must put member=CN=Doe\\, Jane, OU=unit, OU=People or member=CN=Doe, Jane, OU=unit, OU=People Does: member=CN=Doe\2C Jane, OU=unit, OU=People Also works? I have written a patch that at the moment can implement either of those two fixes by encoding the filter. I have tried to find the answer at the LDAP specifications at http://rfc.sunsite.dk/rfc/rfc2253.html. Is this just Active Directory messing up? Does my fix seem reasonable? What is the best method to fix my problems and stay within LDAP specifications? Any feedback or suggestions are welcomed. Thanks, Jessica - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
[EMAIL PROTECTED] wrote:
What about a 1.2.5 release soon ?
billbarker2003/06/26 20:10:44
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Port from apache-1.3
Revision ChangesPath
1.80 +6 -4 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.79
retrieving revision 1.80
diff -u -r1.79 -r1.80
--- mod_jk.c 18 Jun 2003 15:48:14 - 1.79
+++ mod_jk.c 27 Jun 2003 03:10:43 - 1.80
@@ -2280,16 +2280,18 @@
return OK;
} else if(conf-alias_dir != NULL) {
+char *clean_uri = ap_pstrdup(r-pool, r-uri);
+ap_no2slash(clean_uri);
/* Automatically map uri to a context static file */
jk_log(conf-log, JK_LOG_DEBUG,
mod_jk::jk_translate, check alias_dir: %s\n,
conf-alias_dir);
-if (strlen(r-uri) 1) {
+if (strlen(clean_uri) 1) {
/* Get the context directory name */
char *context_dir = NULL;
char *context_path = NULL;
char *child_dir = NULL;
-char *index = r-uri;
+char *index = clean_uri;
char *suffix = strchr(index+1,'/');
if( suffix != NULL ) {
int size = suffix - index;
@@ -2327,7 +2329,7 @@
finfo.filetype = APR_NOFILE;
apr_stat(finfo,context_path,APR_FINFO_TYPE,r-pool);
if( finfo.filetype == APR_DIR ) {
-char *escurl = ap_os_escape_path(r-pool, r-uri, 1);
+char *escurl = ap_os_escape_path(r-pool, clean_uri, 1);
char *ret = ap_pstrcat(r-pool,conf-alias_dir,escurl,NULL);
/* Add code to verify real path ap_os_canonical_name */
if( ret != NULL ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
BTW, we need a fix for this libtool problem. What about adding libtool in configure.in via a --with-libtool ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 08:55 --- I misused WORKSFORME resolution (ehh, I should have read FM ;-), so I am setting the status back to REOPEN. I'm sorry, guys! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 SSI-Servlet produces invalid character encoding information --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 09:15 --- Created an attachment (id=7011) tgzed org.apache.catalina.ssi src-package with quick fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 SSI-Servlet produces invalid character encoding information --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 09:22 --- Created an attachment (id=7012) servlets-ssi.jar bin-package with quick fix - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10558] - encodeURL form submit doesn't include hidden form variables
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10558 encodeURL form submit doesn't include hidden form variables --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 09:33 --- According to the servlet spec, you can not get parameters from a POST request which has a content type multitype/form-data. See SRV.4.1.1 When Parameters Are Available in the servlet spec 2.3 for a detail. I would recommend you to use commons-fileupload. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21138] New: - javac cannot compile BaseDirContextTestCase.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21138.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21138
javac cannot compile BaseDirContextTestCase.java
Summary: javac cannot compile BaseDirContextTestCase.java
Product: Tomcat 4
Version: Nightly Build
Platform: All
OS/Version: All
Status: NEW
Severity: Blocker
Priority: Other
Component: Tester
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When using j2sdk-1.4 and JUnit-3.8.1, javac cannot compile
BaseDirContextTestCase.java, which uses
`Assert#assert(String, boolean)'.
Replacing `assert(' with `assertTrue(' are required to fix this problem.
$ java -version
java version 1.4.1_03
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_03-b02)
Java HotSpot(TM) Client VM (build 1.4.1_03-b02, mixed mode)
$ ant test
... (omit) ...
build-tests:
[javac] Compiling 1 source file to
/opt/src/cvs.apache.org/jakarta-tomcat-4.0/catalina/build/tests
[javac] This version of java does not support the classic compiler;
upgrading to modern
[javac]
/opt/src/cvs.apache.org/jakarta-tomcat-4.0/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java:250:
warning: as of release 1.4, assert is a keyword, and may not be used as an
identifier
[javac] assert(WEB-INF entry is a DirContext,
[javac] ^
[javac]
/opt/src/cvs.apache.org/jakarta-tomcat-4.0/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java:250:
cannot resolve symbol
[javac] symbol : method assert (java.lang.String,boolean)
[javac] location: class org.apache.naming.resources.BaseDirContextTestCase
[javac] assert(WEB-INF entry is a DirContext,
[javac] ^
[javac] 1 error
[javac] 1 warning
BUILD FAILED
file:/opt/src/cvs.apache.org/jakarta-tomcat-4.0/catalina/build.xml:973: Compile
failed; see the compiler error output for details.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21138] - javac cannot compile BaseDirContextTestCase.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21138. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21138 javac cannot compile BaseDirContextTestCase.java --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 11:23 --- Created an attachment (id=7015) Please apply this patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-5
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-27/jakarta-tomcat-5.html Buildfile: build.xml prepare-release: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0 [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src init: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib deploy-static: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib BUILD FAILED /home/rubys/jakarta/jakarta-tomcat-5/build.xml:156: Warning: Could not find file /usr/local/commons-daemon/bin/jsvc.tar.gz to copy. Total time: 10 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21146] New: - Request variables from Apache are not available in Tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21146. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21146 Request variables from Apache are not available in Tomcat Summary: Request variables from Apache are not available in Tomcat Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Certain Request variables are not available to Tomcat, when the request originates from Apache 2.0. There are also differences depending on the connector used (jk or jk2). We use a snoop servlet for listing Request info, headers and additional variables. with jk --- Remote user: none Remote host: none Authorization type: Negotiate with jk2 --- Remote user: DOMAIN\admin Remote host: pc3358e.nt.domain.com Authorization type: none Full list Apache 2.0.46 (win32) - Tomcat 4.1.24 (win32) - mod_jk-1.2.4-2.0.46-w32 apache httpd.conf: - # # Configure mode_jk # JkWorkersFile C:\Data\Apache\ApacheX0\Tomcat\conf\workers.properties JkLogFile C:\Data\Apache\ApacheX0\logs\mod_jk.log JkLogLevel info JkEnvVar REMOTE_USER NONE - snoop results: Requested URL: == http://tango:16000/public/snoop Request information: Request method: GET Request URI: /public/snoop Request protocol: HTTP/1.1 Servlet path: /snoop Path info: none Path translated: none Query string: none Content length: 0 Content type: none Server name: tango Server port: 16000 Remote user: none Remote address: 10.201.128.161 Remote host: none Authorization type: Negotiate Character Encoding: none Requested Session Id: none Scheme: http Request headers: authorization: Negotiate YIIFPgYGKwYBBQUCoIIFMjCCBS6gMDsnip content-length: 0 accept-encoding: gzip, deflate connection: Keep-Alive host: tango:16000 accept-language: en-gb user-agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) accept: */* Extra Servlet attributes: = REMOTE_USER = DOMAIN\admin Response Information: = MIME character encoding: ISO-8859-1 Apache 2.0.46 (win32) - Tomcat 4.1.24 (win32) - mod_jk2-2.0.2-2.0.43-w32 Apache 2.0.46 (win32) - Tomcat 4.1.24 (win32) - mod_jk2-2.0.3-dev-2.0.46-w32 jk2.properties: - # Set the desired handler list handler.list=channelSocket,request request.tomcatAuthentication=false # # Override the default port for the socketChannel channelSocket.port=8019 - snoop results: Requested URL: == http://tango:16000/public/snoop Request information: Request method: GET Request URI: /public/snoop Request protocol: HTTP/1.1 Servlet path: /snoop Path info: none Path translated: none Query string: none Content length: 0 Content type: none Server name: tango Server port: 16000 Remote user: DOMAIN\admin Remote address: 10.201.128.161 Remote host: pc3358e.nt.domain.com Authorization type: none Character Encoding: none Requested Session Id: none Scheme: http Request headers: accept: */* accept-language: en-gb accept-encoding: gzip, deflate user-agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) host: tango:16000 connection: Keep-Alive authorization: Negotiate YIIFPgYGKwYBBQUCoIIFMjCCBS6gMDsnip content-length: 0 No extra attributes === Response Information: = MIME character encoding: ISO-8859-1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 4091] - custom host with unpackWARs=true don't expand war automatically - work around fails log4j!
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4091. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4091 custom host with unpackWARs=true don't expand war automatically - work around fails log4j! [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|INVALID | Summary|custom host with|custom host with |unpackWARs=true don't |unpackWARs=true don't |expand war automatically|expand war automatically - ||work around fails log4j! --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 15:44 --- We ran into the same problem. Our log4j.properties is located in the top level directory of the war file. Now we get the following error! log4j:ERROR Could not read configuration file [nulllog4j.properties]. java.io.FileNotFoundException: nulllog4j.properties (The system cannot find the file specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:103) at java.io.FileInputStream.init(FileInputStream.java:66) at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:300) at org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:318) at com.privasphere.privalope.util.Log4JServlet.init(Log4JServlet.java:34) at javax.servlet.GenericServlet.init(GenericServlet.java:256) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:935) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3420) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3608) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:738) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2190) at org.apache.catalina.startup.Catalina.start(Catalina.java:512) at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) log4j:ERROR Ignoring configuration file [nulllog4j.properties]. dataSource = jdbc:mysql://127.0.0.1:3306/privalope log4j:WARN No appenders could be found for logger (Database). log4j:WARN Please initialize the log4j system properly. === any thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/commonjk_uri_worker_map.c jk_uri_worker_map.h
On Thu, 27 Jun 2003 [EMAIL PROTECTED] wrote: billbarker2003/06/26 19:54:18 Modified:jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h Log: Fix problem with URLs that contain //. This is essentially what Apache/httpd does in location_walk. Make sure you realize that, especially on windows, this is unlikely to be sufficient to fix this class of problems unless there is other code somewhere that I didn't see when I checked. What happens, for example, if you have a directory /directory/ that also has a 8.3 name direct~1 and access the direct~1 form of the name? What prevents the rule mapping /directory/*.jsp to tomcat from being bypassed? This is one of the reasons why the Apache documentation tells you never to use a Location section to protect or control access to the filesystem, but instead to use a Directory section. Due to filename variance there are many different filenames, and hence URLs, that can be used to access the same actual file bypassing the protection (in this case mapping). This requires the filename be canonicalized for comparisons, which is partly done in directory_walk() in Apache. Certainly, doing this right is complex. But that is one of the exact reasons I run Apache in front of Tomcat and why I want Tomcat and the connectors to it to have the smallest possible duplicate codepath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21148] New: - catalina out not written when started via *.bat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21148. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21148 catalina out not written when started via *.bat Summary: catalina out not written when started via *.bat Product: Tomcat 4 Version: 4.1.24 Platform: PC URL: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6229 OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] The above-referenced URL claims that catalina.out is always written. Unfortunately when I use .../Tomcat 4.1/bin/startup.bat out of an exec task of ant, this is not the case. How can I force catalina.out to be written all the time since it may contain error messages I don't see anywhere else? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.cjk_uri_worker_map.h
Marc Slemko wrote: On Thu, 27 Jun 2003 [EMAIL PROTECTED] wrote: billbarker2003/06/26 19:54:18 Modified:jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h Log: Fix problem with URLs that contain //. This is essentially what Apache/httpd does in location_walk. Make sure you realize that, especially on windows, this is unlikely to be sufficient to fix this class of problems unless there is other code somewhere that I didn't see when I checked. What happens, for example, if you have a directory /directory/ that also has a 8.3 name direct~1 and access the direct~1 form of the name? What prevents the rule mapping /directory/*.jsp to tomcat from being bypassed? This is one of the reasons why the Apache documentation tells you never to use a Location section to protect or control access to the filesystem, but instead to use a Directory section. Due to filename variance there are many different filenames, and hence URLs, that can be used to access the same actual file bypassing the protection (in this case mapping). This requires the filename be canonicalized for comparisons, which is partly done in directory_walk() in Apache. Certainly, doing this right is complex. But that is one of the exact reasons I run Apache in front of Tomcat and why I want Tomcat and the connectors to it to have the smallest possible duplicate codepath. If you want to be very secure, you sue Apache in front of Tomcat, and tomcats located on other machines. In such case you use ajp13, and with this configuration, I DIDN'T HAVE ANY PROBLEM with '//' since it's handle by tomcat (tested with 3.3.1a), since Apache web server couldn't read NON LOCAL DATAS isn't it ? The general rule for security is to make use of JkMount to ROOT : JkMount /webappx/servlet/ ajpworker JkMount /webappx/*.jspajpworker Or JkMount /webappx/* ajpworker And in your jsp/servlet/..., you put ref to Apache handled element, like images, html in /images, /text, /, which are NOT in the /webappx scope and so will be server by Apache. You seems very aware of Apache Internals and I reiterate our proposal (at least Remy and I), to provide fixes. And remember La Fontaine : 'Sans mentir, si votre ramage, Se rapporte à votre plumage, Vous êtes le phénix des hôtes de ces bois' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/commonjk_uri_worker_map.c jk_uri_worker_map.h
On Fri, 27 Jun 2003, Henri Gomez wrote: If you want to be very secure, you sue Apache in front of Tomcat, and tomcats located on other machines. In such case you use ajp13, and with this configuration, I DIDN'T HAVE ANY PROBLEM with '//' since it's handle by tomcat (tested with 3.3.1a), since Apache web server couldn't read NON LOCAL DATAS isn't it ? The general rule for security is to make use of JkMount to ROOT : JkMount /webappx/servlet/ ajpworker JkMount /webappx/*.jspajpworker Or JkMount /webappx/* ajpworker And in your jsp/servlet/..., you put ref to Apache handled element, like images, html in /images, /text, /, which are NOT in the /webappx scope and so will be server by Apache. Thanks for the suggestion, it certainly is one option that can work for some people in some situations. However, it isn't a very good general purpose solution for a variety of reasons, and certainly should not be necessary. You seems very aware of Apache Internals and I reiterate our proposal (at least Remy and I), to provide fixes. Enough with the attitude. I'm just trying to point out specific instances where things are not or may not be handled properly so perhaps someone can fix them if they so desire. I am making no demands that anyone jump up and do so, nor blaming anyone for anything, but simply pointing out what is broken and why. Is it reallly the case around here that people don't want to hear about specifics of bugs and security holes that impact a large percent of users unless a patch is provided? All I am doing is trying to make sure people are aware that the particular case of a double '/' is only a subset of the more general issue that has to be dealt with. Your if you don't like it go fix it yourself responses are not appreciated nor are they condusive to making people feel welcome or in any mood to contribute anything. I already said I don't have time to do that right now, but will likely do so in the future if it is still broken by the time I need it to work right. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20029] - catalina.sh - command stop -force not working
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20029. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20029 catalina.sh - command stop -force not working --- Additional Comments From [EMAIL PROTECTED] 2003-06-27 22:39 --- But removing the exec will make shutdown.sh wait until shutdown is complete, not return right away like now. For a large system, this can easily be several seconds (or more, depending on custom shutdown code in user webapps). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21157] New: - CookieExample is setting cookie after writing data
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21157. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21157 CookieExample is setting cookie after writing data Summary: CookieExample is setting cookie after writing data Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A servlet can not set the headers and cookies after writing data to the servlet's output stream. Once the servlet writes data, headers are committed. However CookieExample writes some data first before doing addCookie on the response. The reason why this code works at all even with the above bug is: The CookieExample is only writing a small amount of data before doing response.addCookie. That data is still held in buffer and not yet sent over the wire. Hence the headers are not yet committed. So it is pure luck that this example works. You can easily expose the bug by writing say 20K characters in this example before response.addCookie is called. You will see that the cookies that are adding to response are not actually sent back to client. Fix is simple. Move up the response.addCookie() before response.getWriter() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
billbarker2003/06/27 19:55:55 Modified:jk/native/common jk_uri_worker_map.c Log: Reverting to the httpd symbol. Having thought about this, I think that supporting UNC paths in mod_jk doesn't have a valid use case, and is only likely to cause problems on Windows. Since this part of the code doesn't include the httpd headers, the symbol is always undefined unless someone explicitly adds it to their build. Revision ChangesPath 1.16 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c Index: jk_uri_worker_map.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- jk_uri_worker_map.c 27 Jun 2003 02:54:17 - 1.15 +++ jk_uri_worker_map.c 28 Jun 2003 02:55:55 - 1.16 @@ -459,7 +459,7 @@ s = d = name; -#if defined(WIN32) +#if defined(HAVE_UNC_PATHS) /* Check for UNC names. Leave leading two slashes. */ if (s[0] == '/' s[1] == '/') *d++ = *s++; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fw: Howto compile mod_jk2 under windows?
Hello gurus, This question I asked on Tomcat user list, But they let me ask it here. Who can help me please? -Ares - Original Message - From: Ares Liu [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Friday, June 27, 2003 2:21 PM Subject: Re: Howto compile mod_jk2 under windows? After I hit build button, the MSVC debug windows displayed as follow: Configuration: mod_jk2 - Win32 Debug Creating resources from ..\..\common\jk_logger_win32_message.mc MC: may only specify one message file to compile. MC: may only specify one message file to compile. MC: may only specify one message file to compile. MC: may only specify one message file to compile. Microsoft (R) Message Compiler Version 1.00.5239 Copyright (c) Microsoft Corp 1992-1995. All rights reserved. usage: MC [-?vcdwso] [-m maxmsglen] [-h dirspec] [-e extension] [-r dirspec] [-x dbgFileSpec] [-u] [-U] filename.mc -? - displays this message -v - gives verbose output. -c - sets the Customer bit in all the message Ids. -d - FACILTY and SEVERITY values in header file in decimal. Sets message values in header to decimal initially. -w - warns if message text contains non-OS/2 compatible inserts. -s - insert symbolic name as first line of each message. -o - generate OLE2 header file (use HRESULT definition instead of status code definition) -m maxmsglen - generate a warning if the size of any message exceeds maxmsglen characters. -h pathspec - gives the path of where to create the C include file Default is .\ -e extension - Specify the extension for the header file. From 1 - 3 chars. -r pathspec - gives the path of where to create the RC include file and the binary message resource files it includes. Default is .\ -x pathspec - gives the path of where to create the .dbg C include file that maps message Ids to their symbolic name. -u - input file is Unicode. -U - messages in .BIN file should be Unicode. filename.mc - gives the names of a message text file to compile. Generated files have the Archive bit cleared. Error executing c:\windows\system32\cmd.exe. mod_jk2.dll - 1 error(s), 1 warning(s) -- Nuclear Science Technology Virtual Research Center http://nst.pku.edu.cn -- Original Message --- From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thu, 26 Jun 2003 22:07:20 -0700 Subject: Re: Howto compile mod_jk2 under windows? I'm neither a Windows user nor a Jk2 user, but just by looking, there are '.dsp' files under all of server/apache13, server/apache2, and server/isapi. Assuming that you have MSVC installed, it should be enough to click on the file and hit the 'build' button. Ares Liu [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I need newest mod_jk2 under windows. But I don't know how to compile it. Who can give me a tutorial? Thanks! -Ares -- Nuclear Science Technology Virtual Research Center http://nst.pku.edu.cn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End of Original Message --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Redhat 8.0 / 9.0 still use 2.0.40 (+ security fixes)
At 06:47 AM 6/27/2003, Mark J Cox wrote: For those who wonder why Redhat didn't update Apache 2.0 in distro 8.0 and 9.0, just read : http://www.redhat.com/advice/speaks_backport.html Apache httpd was an example that I happened to remember when writing that explanation - Apache is far from the worst offender to mix security updates with other changes in a new release ;) This is a good example of why Jeff Trawick and I spent many posts arguing the benefits of maintaining binary compatibility from update to update within the remaining releases of Apache 2.0 :-) Unfortunately, that doesn't help 2.0.40 deployments or earlier. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why Redhat 8.0 / 9.0 still use 2.0.40 (+ security fixes)
For those who wonder why Redhat didn't update Apache 2.0 in distro 8.0 and 9.0, just read : http://www.redhat.com/advice/speaks_backport.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Redhat 8.0 / 9.0 still use 2.0.40 (+ security fixes)
For those who wonder why Redhat didn't update Apache 2.0 in distro 8.0 and 9.0, just read : http://www.redhat.com/advice/speaks_backport.html Apache httpd was an example that I happened to remember when writing that explanation - Apache is far from the worst offender to mix security updates with other changes in a new release ;) Mark -- Mark J Cox ... www.awe.com/mark Apache Software Foundation . OpenSSL Group . Apache Week editor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[TRICK] mod_jk build on Redhat 8.0 / 9.0
Under Redhat 8.0/9.0, the Apache 2.0 installed is 2.0.40 with security fixes. But the apxs is still the one from 2.0.40 so the apxs -q LIBTOOL, used in configure didn't works. A solution for RH users to build jk 1.2.4 is : ./buildconf.sh ./configure --with-apxs=/usr/sbin/apxs make LIBTOOL=/etc/httpd/build/libtool cp apache-2.0/mod_jk.so /usr/lib/httpd/modules For your information, the jpackage project (www.jpackage.org), is working on releasing binary rpms for jk and jk2 for many Linux distribtuions (i386, ppc, RH/MDK...) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
