Re: Improving mod_jk URI forwarding
Rainer Jung wrote: Mladen Turk wrote: Can you write a simple example of the uris that make the problem and why we would need to encode the %. How it is passed now, and how it would be passed with your proposal. Original URI: /myapp/%252e%252e/otherapp/danger JkMount /myapp/* Apache httpd will correctly decode the URI to /myapp/%2e%2e/otherapp/danger mod_jk does map it *correctly* to /myapp and forwards it to Tomcat. It does not IMO, and that's what I'm talking. Inside mod_jk we should decode /myapp/%2e%2e/otherapp/danger to /myapp/../otherapp/danger Do a normalization of the uri that will end up as /otherapp/danger before hitting map_uri_to_worker If there is no JkMount for /otherapp/ it will be denied, if it is, the rewritten uri /otherapp/danger will be send instead /myapp/%2e%2e/otherapp/danger. Of course we can simply send /myapp/%2e%2e/otherapp/danger to tomcat if the match is OK for /otherapp/, and let the tomcat do a normalization once again. In that case we won't need to encode the normalized uri inside mod_jk once more. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
The iSeries (i5/OS) version need stuff added after 1.22 so it will be available in 1.24... 2007/5/20, Guenter Knauf [EMAIL PROTECTED]: Hi all, The Apache Tomcat team is pleased to announce the immediate availability of version 1.2.23 of the Apache Tomcat Connectors. somehow I've a problem with our distribution directories.. currently I see: http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/aix/ empty folder http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/freebsd/ empty folder http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/iseries/ empty folder http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/linux/ jk-1.2.21 http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/macosx/ empty folder http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/netware/ jk-1.2.23 http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/solaris/ jk-1.2.21 http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/ jk-1.2.21 jk-1.2.22 jk-1.2.23 http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win64/ jk-1.2.23 this makes me ask a couple of questions: 1) why do some folders list older versions while others do not? 2) why do we have a history of the last 3 versions with Win32 but no history for any other platform? 3) where do the older versions go? 4) why do we prefix the directories with 'jk-' although 'jk' is already in the path? For NetWare I would like to have at least the 1.2.15 release up again since that was last version where I supported Apache 1.3.x and Netscape - I point to this version in the README but obviously nobody can download anymore (except from my personal homedir). Sure its no problem for me just copy this over, but first I wanted to discuss that here, and ask if I probably missed that there's somewhere an archive from where older versions can be downloaded... Then I would like to have at least the last three versions always up, + the last version we have for any platforms where we cant build self, or where the maintainer is currently busy and some versions behind. This makes also sense in case it turns out later that we broke something with a release, and users may have to switch back. what do you think? greets, Guen. - 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: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Hi Mark, 1) why do some folders list older versions while others do not? Probably because they are the latest stable version for that platform. 2) why do we have a history of the last 3 versions with Win32 but no history for any other platform? Because the old version weren't cleaned out. They should have been. 3) where do the older versions go? They are automatically copied to archive.apache.org which is linked off the Tomcat homepage. I found though that the README.html files which are commonly used to provide further informations about the releases are not copied. I probably missed that there's somewhere an archive from where older versions can be downloaded... This is not correct. It is available along with all other versions in the archive. that was what I missed - thanks! Then I would like to have at least the last three versions always up, + the last version we have for any platforms where we cant build self, or where the maintainer is currently busy and some versions behind. -1. dist (and the mirrors) should only have the current stable version and the latest non-stable release if there has been once since the last stable release. so does this mean if we dont have a binary from current version the directory should remain empty? Or should there then remain the last version we have as you wrote in 1) ? If they should remain empty then I would find it useful to have a README in which points to the related archive, and I volunteer to create these if there's agreement. There are probably a lot of users who just link to the dist directory of their platform, and would find a poiter to the archives useful. Then I found on the main docu page: http://tomcat.apache.org/connectors-doc/ that there are direct links to the previous source versions, but all end up in a 'NOT FOUND'; should we change these to point to the archive now? Guen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Hi Henri, The iSeries (i5/OS) version need stuff added after 1.22 so it will be available in 1.24... dont get me wrong - I didnt want to kick here, it was only a question why we had different handling for each platform Guen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42412] - java.lang.ClassCastException: javax.mail.Session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42412. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42412 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 05:07 --- This works for me with a simple test case. There are, however, some more complex use cases where the jars should only be in common/lib and having the jars in both locations will cause this issue. The information in this report points to an application configuration/deployment issue rather than a Tomcat bug. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Guenter Knauf wrote: 3) where do the older versions go? They are automatically copied to archive.apache.org which is linked off the Tomcat homepage. I found though that the README.html files which are commonly used to provide further informations about the releases are not copied. For. Tomcat 4/5/6 the README.html stays pretty much the same and the per release information is found in a file called RELEASE-NOTES. This file is copied to the archives. I believe this is standard across Apache so we should use it for the connectors too. Then I would like to have at least the last three versions always up, + the last version we have for any platforms where we cant build self, or where the maintainer is currently busy and some versions behind. -1. dist (and the mirrors) should only have the current stable version and the latest non-stable release if there has been once since the last stable release. so does this mean if we dont have a binary from current version the directory should remain empty? Or should there then remain the last version we have as you wrote in 1) ? Every rule has an exception ;). You are right. For binaries, dist should contain the latest *available* stable binary and the the latest *available* non-stable release if it is more more recent than the latest stable one. Then I found on the main docu page: http://tomcat.apache.org/connectors-doc/ that there are direct links to the previous source versions, but all end up in a 'NOT FOUND'; should we change these to point to the archive now? I would point all of these to the download pages. We should never include links directly to the Apache download area fo rthe latest release. We should use the mirrors. Pointing to our download pages is the quickest way of doing this. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug with ETag in 304 responses - dev input requested
Len Popp wrote: The issue was originally raised by Joe Mun on the Tomcat Users list: http://marc.info/?l=tomcat-userm=117934336727314w=2 I looked at the behaviour in Tomcat 5.5.23 and it looks like Tomcat is not handling ETag headers as required by the HTTP spec, when it returns a 304 (not modified) response for a file. For a 304 response, the spec says: The response MUST include the following header fields: ... - ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request (RFC 2616 10.3.5) I take that to mean that if the server includes ETag headers when it sends files, it must also include them when it sends 304's for those same files. However Tomcat 5.5 doesn't do this. When a static file is requested, Tomcat includes the ETag when it sends the file (with 200 status code) but omits it if it sends a status 304 response. I did a simple test to verify this, requesting the same file twice to get first a 200 and then a 304 response from Tomcat. The headers, as reported by Firefox's Live HTTP Headers plugin, can be seen here: http://marc.info/?l=tomcat-userm=117950251422474w=2 Am I correct that this is incorrect behaviour? Yes, I think that's correct. It's bug. Julian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger
No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it
is not correct to end up with /otherapp/danger as a decoded URL. A
percent sign is a valid character in a ressource path. If one wants to
use it in ressource paths, one needs to encode it ('%25'), and it is not
allowed to decode '%25XX' again after decoding to '%XX' once.
So %252e - %2e and that's it, no further decoding. It is not a '.',
because it is decoded already.
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Do a normalization of the uri that will end up as
/otherapp/danger before hitting map_uri_to_worker
If there is no JkMount for /otherapp/ it will be
denied, if it is, the rewritten uri /otherapp/danger
will be send instead /myapp/%2e%2e/otherapp/danger.
Of course we can simply send /myapp/%2e%2e/otherapp/danger
to tomcat if the match is OK for /otherapp/,
and let the tomcat do a normalization once again.
As I said, double decoding (again) is not allowed and is the source of
all evil.
In that case we won't need to encode the normalized
uri inside mod_jk once more.
I'm sure we need to, because double encoding is not allowed, but Tomcat
unfortunately does a second decoding.
Some evidence:
0) RFC 2396, RFC 3986
=
http://www.ietf.org/rfc/rfc2396.txt
Section 2.4.2. When to Escape and Unescape:
Implementers should be careful not to
escape or unescape the same string more than once, since unescaping
an already unescaped string might lead to misinterpreting a percent
data character as another escaped character, or vice versa in the
case of escaping an already escaped string.
and even stricter the younger
http://tools.ietf.org/html/rfc3986
2.4. When to Encode or Decode
Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.
1) IIS Bug
==
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333
which leads to
http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx
What's wrong with the decoding operation?
There's nothing wrong with the decoding operation per se. The
vulnerability results because, through an implementation flaw, the
decoding operation is performed a second time, after the security checks
on the request have been completed.
2) mod_security Bug
===
http://www.modsecurity.org/download/CHANGES
BUG Fixed a double URL-decoding bug (Apache first, then us), which
could sometimes lead to a false positive.
3) DAV Bugs
===
http://dav.sourceforge.net/
The following bugs should have gone:
* [ 1519718 ] davfs2 fails to properly decode complex escape sequences
* [ 1522903 ] chokes on directory names containing ' _ % characters
* [ 1539444 ] mounting of webdav drive fails
* [ 1539445 ] unable to access files in mounted webdav drive
* [ 1558525 ] davfs2-1.0.2_p20060820 mount fails
These bugs were related to ... and incorrect double url-decoding of urls.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
I'm trying to follow this thread, I hope i'm not duplicating things. Mark Thomas wrote: Guenter Knauf wrote: this makes me ask a couple of questions: Remember we only *have* to make the source available. Anything we do on the binary front is just being helpful and the release manager is unlikely to have access to build binaries for all platforms. 1) why do some folders list older versions while others do not? Probably because they are the latest stable version for that platform. Yes, I tried to delete all older versions of binaries (tried = as far as permissions allowed), but for sme platforms we don't have 1.2.23 binares, so I kept the latest available ones. There is an open point, if we can find a way of distributing contributed builds. I know we could get some, but there were valid concerns, if we shold sign those with our own keys. So we would need some notion of contributed and could put the binaries there. 2) why do we have a history of the last 3 versions with Win32 but no history for any other platform? Because the old version weren't cleaned out. They should have been. I had no permissions to delete them, I'll write to the owners directly to remove them. 3) where do the older versions go? They are automatically copied to archive.apache.org which is linked off the Tomcat homepage. 4) why do we prefix the directories with 'jk-' although 'jk' is already in the path? No particular reason I am aware of. We just do. Seems to be history, and you decided to drop it for Netware :) For NetWare I would like to have at least the 1.2.15 release up again since that was last version where I supported Apache 1.3.x and Netscape - I point to this version in the README but obviously nobody can download anymore (except from my personal homedir). Sure its no problem for me just copy this over, but first I wanted to discuss that here, and ask if I probably missed that there's somewhere an archive from where older versions can be downloaded... This is not correct. It is available along with all other versions in the archive. Then I would like to have at least the last three versions always up, + the last version we have for any platforms where we cant build self, or where the maintainer is currently busy and some versions behind. -1. dist (and the mirrors) should only have the current stable version and the latest non-stable release if there has been once since the last stable release. This makes also sense in case it turns out later that we broke something with a release, and users may have to switch back. Again, that is what the archives are for. So if the archives are important, we could replace the link text archives... with something a little more prominent. Suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539895 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/manager/HTMLManagerServlet.java webapps/docs/changelog.xml
Author: rjung
Date: Sun May 20 10:12:08 2007
New Revision: 539895
URL: http://svn.apache.org/viewvc?view=revrev=539895
Log:
Fix BZ 42459: Manager webap table format error
for stopped and undeployed webapps.
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java?view=diffrev=539895r1=539894r2=539895
==
---
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
(original)
+++
tomcat/tc6.0.x/trunk/java/org/apache/catalina/manager/HTMLManagerServlet.java
Sun May 20 10:12:08 2007
@@ -1006,7 +1006,7 @@
nbsp;a href=\{6}\ onclick=\return(confirm('''Are you sure?
This will delete the application.'''))\{7}/anbsp;\n +
/small\n +
/td\n +
-/tr\n;
+/tr\ntr/tr\n;
private static final String STARTED_NONDEPLOYED_APPS_ROW_BUTTON_SECTION =
td class=\row-left\ bgcolor=\{13}\ rowspan=\2\\n +
@@ -1017,7 +1017,7 @@
nbsp;{7}nbsp;\n +
/small\n +
/td\n +
-/tr\n;
+/tr\ntr/tr\n;
private static final String STOPPED_NONDEPLOYED_APPS_ROW_BUTTON_SECTION =
td class=\row-left\ bgcolor=\{13}\ rowspan=\2\\n +
@@ -1028,7 +1028,7 @@
nbsp;{7}nbsp;\n +
/small\n +
/td\n +
-/tr\n;
+/tr\ntr/tr\n;
private static final String DEPLOY_SECTION =
/table\n +
Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?view=diffrev=539895r1=539894r2=539895
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Sun May 20 10:12:08 2007
@@ -31,6 +31,13 @@
/fix
/changelog
/subsection
+ subsection name=Webapps
+changelog
+ fix
+ bug42459/bug: Tomcat Web Application Manager table error (rjung)
+ /fix
+/changelog
+ /subsection
/section
section name=Tomcat 6.0.13 (remm)
subsection name=Catalina
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.13
I fixed this (BZ 42459) now in r539895. Remy Maucherat wrote: Tim Funk wrote: The only 2 things I noticed (which aren't a big deal) The index pages had a bad links to the docs. (Now fixed) The status screen has a rendering bug when a webapp is stopped. I didn't have a chance to dig into it - but its not a big deal either. I can confirm this. It does not prevent using the page, but it becomes a bit hard to read. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42459] - Tomcat Web Application Manager table error
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42459. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42459 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version|Windows XP |All Platform|PC |All Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 10:15 --- Fixed in r539895 for 6.0.14. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Then I found on the main docu page: http://tomcat.apache.org/connectors-doc/ that there are direct links to the previous source versions, but all end up in a 'NOT FOUND'; should we change these to point to the archive now? I would point all of these to the download pages. We should never include links directly to the Apache download area fo rthe latest release. We should use the mirrors. Pointing to our download pages is the quickest way of doing this. Good point. I'll look into the index page and the various news pages to make their links more lasting. Unfortunately since the download script has no intelligence concerning old releases and the archive this will also mean making them more unspecific. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
For me there is nothing wrong except it adds 2 JKoptions or 3 :-)
We know that Tomcat is going to normalise a url we have already
normalised. Shouldn't we check that a second normalisation (like the
Tomcat one) gives a different url and if yes have a flag to return
forbidden? (Yes that would be a 4th option).
Cheers
Jean-Frederic
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger
No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it
is not correct to end up with /otherapp/danger as a decoded URL. A
percent sign is a valid character in a ressource path. If one wants to
use it in ressource paths, one needs to encode it ('%25'), and it is not
allowed to decode '%25XX' again after decoding to '%XX' once.
So %252e - %2e and that's it, no further decoding. It is not a '.',
because it is decoded already.
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Do a normalization of the uri that will end up as
/otherapp/danger before hitting map_uri_to_worker
If there is no JkMount for /otherapp/ it will be
denied, if it is, the rewritten uri /otherapp/danger
will be send instead /myapp/%2e%2e/otherapp/danger.
Of course we can simply send /myapp/%2e%2e/otherapp/danger
to tomcat if the match is OK for /otherapp/,
and let the tomcat do a normalization once again.
As I said, double decoding (again) is not allowed and is the source of
all evil.
In that case we won't need to encode the normalized
uri inside mod_jk once more.
I'm sure we need to, because double encoding is not allowed, but Tomcat
unfortunately does a second decoding.
Some evidence:
0) RFC 2396, RFC 3986
=
http://www.ietf.org/rfc/rfc2396.txt
Section 2.4.2. When to Escape and Unescape:
Implementers should be careful not to
escape or unescape the same string more than once, since unescaping
an already unescaped string might lead to misinterpreting a percent
data character as another escaped character, or vice versa in the
case of escaping an already escaped string.
and even stricter the younger
http://tools.ietf.org/html/rfc3986
2.4. When to Encode or Decode
Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.
1) IIS Bug
==
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333
which leads to
http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx
What's wrong with the decoding operation?
There's nothing wrong with the decoding operation per se. The
vulnerability results because, through an implementation flaw, the
decoding operation is performed a second time, after the security checks
on the request have been completed.
2) mod_security Bug
===
http://www.modsecurity.org/download/CHANGES
BUG Fixed a double URL-decoding bug (Apache first, then us), which
could sometimes lead to a false positive.
3) DAV Bugs
===
http://dav.sourceforge.net/
The following bugs should have gone:
* [ 1519718 ] davfs2 fails to properly decode complex escape sequences
* [ 1522903 ] chokes on directory names containing ' _ % characters
* [ 1539444 ] mounting of webdav drive fails
* [ 1539445 ] unable to access files in mounted webdav drive
* [ 1558525 ] davfs2-1.0.2_p20060820 mount fails
These bugs were related to ... and incorrect double url-decoding of urls.
Regards,
Rainer
-
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: Improving mod_jk URI forwarding
Jean-Frederic wrote: On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote: Before I answer, let me first ask a question: What's wrong withg my suggestion? Or even better: use the encoding done with mod_proxy_ajp? For me there is nothing wrong except it adds 2 JKoptions or 3 :-) If we think the new way is the correct way, we could have it as the default, letting the old ones there for compatibility with existing configurations as non standard options. The new one would not need an explicit name if it gets to be the standard. We know that Tomcat is going to normalise a url we have already normalised. Shouldn't we check that a second normalisation (like the Tomcat one) gives a different url and if yes have a flag to return forbidden? (Yes that would be a 4th option). Here I try to argue, that encoding '%' before forwarding and decoding by tomcat should lead to the identity operation. I though a little more about it and most likely encoding '+' is also necessary, because besides the '%' decoding, Tomcat will most likely (I have to check) also decode '+' - ' '. At the end I tend to use the same function, that's used in mod_proxy_ajp to reencode before forwarding (although only encoding '%' and '+' would be faster). Rejecting requests with double encoding can already be done by mod_rewrite, because mod_rewrite operates on the decoded URI, so you only need to check for '%' (and '+' if you like). Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion?
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL
+++
Because that is what the SPEC's says.
Cheers
Jean-Frederic
Or even better: use the encoding done with mod_proxy_ajp?
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger
No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it
is not correct to end up with /otherapp/danger as a decoded URL. A
percent sign is a valid character in a ressource path. If one wants to
use it in ressource paths, one needs to encode it ('%25'), and it is not
allowed to decode '%25XX' again after decoding to '%XX' once.
So %252e - %2e and that's it, no further decoding. It is not a '.',
because it is decoded already.
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Do a normalization of the uri that will end up as
/otherapp/danger before hitting map_uri_to_worker
If there is no JkMount for /otherapp/ it will be
denied, if it is, the rewritten uri /otherapp/danger
will be send instead /myapp/%2e%2e/otherapp/danger.
Of course we can simply send /myapp/%2e%2e/otherapp/danger
to tomcat if the match is OK for /otherapp/,
and let the tomcat do a normalization once again.
As I said, double decoding (again) is not allowed and is the source of
all evil.
In that case we won't need to encode the normalized
uri inside mod_jk once more.
I'm sure we need to, because double encoding is not allowed, but Tomcat
unfortunately does a second decoding.
Some evidence:
0) RFC 2396, RFC 3986
=
http://www.ietf.org/rfc/rfc2396.txt
Section 2.4.2. When to Escape and Unescape:
Implementers should be careful not to
escape or unescape the same string more than once, since unescaping
an already unescaped string might lead to misinterpreting a percent
data character as another escaped character, or vice versa in the
case of escaping an already escaped string.
and even stricter the younger
http://tools.ietf.org/html/rfc3986
2.4. When to Encode or Decode
Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.
1) IIS Bug
==
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0333
which leads to
http://www.microsoft.com/technet/security/Bulletin/MS01-026.mspx
What's wrong with the decoding operation?
There's nothing wrong with the decoding operation per se. The
vulnerability results because, through an implementation flaw, the
decoding operation is performed a second time, after the security checks
on the request have been completed.
2) mod_security Bug
===
http://www.modsecurity.org/download/CHANGES
BUG Fixed a double URL-decoding bug (Apache first, then us), which
could sometimes lead to a false positive.
3) DAV Bugs
===
http://dav.sourceforge.net/
The following bugs should have gone:
* [ 1519718 ] davfs2 fails to properly decode complex escape sequences
* [ 1522903 ] chokes on directory names containing ' _ % characters
* [ 1539444 ] mounting of webdav drive fails
* [ 1539445 ] unable to access files in mounted webdav drive
* [ 1558525 ] davfs2-1.0.2_p20060820 mount fails
These bugs were related to ... and incorrect double url-decoding of urls.
Regards,
Rainer
-
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: Improving mod_jk URI forwarding
Well thinking to it I am not very happy with the change: +++ -#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED +#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL +++ Because that is what the SPEC's says. I doubt, that the SPEC is very relevant for the reverse proxy situation of mod_jk. I read the old discussions, and I really got the impression that not much of SPEC compliance was left over. What are we really talking about w.r.t. SPECs? Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Jean-Frederic wrote: On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote: Before I answer, let me first ask a question: What's wrong withg my suggestion? Well thinking to it I am not very happy with the change: +++ -#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED +#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL +++ Because that is what the SPEC's says. The Servlet SPEC says, that the web container should not decode RequestURI. So if the reverse proxy tries to come close to this requirement, it needs to send the URI as unencoded as it can. Now the reverse proxy should have the ability to modify the URI (in the sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is only able to operate on the decoded URI, we have no chance of making this interoperable with forwarding the original undecoded URI. Using the encoding from mod_proxy_ajp we at least try to produce a URI which is as close to the original one, as we can achieve. At least logically the new URI is fine. All in all I think that compat unparsed will result in more user problems as default then the new proposed way. The whole discussion is: 1) At the moment all options have a problem (mod_rewrite, sessions, security) 2) My proposal should be checked if it is secure. If so, it fixes mod_rewrite, sessions and security. This seems to have some value. If you (community) agree on that value, I find it correct to add this option. The answers might depend on - encode only '%' - encode '%' and '+' (easy, performing, but needs some thinking about correctness) - encode like in mod_proxy_ajp (not as performing but more complete) 3) Yes, it will influence how well the container can obey the spec (as two of the three existing options also do). So we could discuss, if the value is huge enough, that we make it the default (and thus need no more explicit option name), or we keep compat unparsed the default and add a new option. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
2007/5/20, Guenter Knauf [EMAIL PROTECTED]: Hi Henri, The iSeries (i5/OS) version need stuff added after 1.22 so it will be available in 1.24... dont get me wrong - I didnt want to kick here, it was only a question why we had different handling for each platform I know, it was more to inform i5/OS users (knock knock, did there is jk i5/OS users around ?) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug with ETag in 304 responses - dev input requested
On 5/20/07, Julian Reschke [EMAIL PROTECTED] wrote: Yes, I think that's correct. It's bug. OK then, I'll submit a bug report. -- Len Popp [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42449] - JNDIRealm does not catch NullPointerException
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42449. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42449 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 11:33 --- fixed with Committed revision 539907. thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42455] - localhost:8080 -- many (?all?) jsp code samples are 404...broken links?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42455. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42455 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 11:49 --- *** This bug has been marked as a duplicate of 41513 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41513] - JSP examples don't work and don't display source
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=41513. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=41513 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 11:49 --- *** Bug 42455 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Rainer Jung [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Jean-Frederic wrote: On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote: Before I answer, let me first ask a question: What's wrong withg my suggestion? Well thinking to it I am not very happy with the change: +++ -#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED +#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL +++ Because that is what the SPEC's says. The Servlet SPEC says, that the web container should not decode RequestURI. So if the reverse proxy tries to come close to this requirement, it needs to send the URI as unencoded as it can. Now the reverse proxy should have the ability to modify the URI (in the sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is only able to operate on the decoded URI, we have no chance of making this interoperable with forwarding the original undecoded URI. Yes, RFC 2616 permits *any* intermediate proxy to alter the URI in *any* way before passing it on. So to be meaningful, the Servlet spec requirement can only apply to the URI that TC receives from the last proxy in the chain. Using the encoding from mod_proxy_ajp we at least try to produce a URI which is as close to the original one, as we can achieve. At least logically the new URI is fine. All in all I think that compat unparsed will result in more user problems as default then the new proposed way. The whole discussion is: 1) At the moment all options have a problem (mod_rewrite, sessions, security) 2) My proposal should be checked if it is secure. If so, it fixes mod_rewrite, sessions and security. This seems to have some value. If you (community) agree on that value, I find it correct to add this option. The answers might depend on - encode only '%' - encode '%' and '+' (easy, performing, but needs some thinking about correctness) We pass the original query string to TC, so there is no point in worrying about '+' (since it only means ' ' in the qs). - encode like in mod_proxy_ajp (not as performing but more complete) 3) Yes, it will influence how well the container can obey the spec (as two of the three existing options also do). So we could discuss, if the value is huge enough, that we make it the default (and thus need no more explicit option name), or we keep compat unparsed the default and add a new option. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Because it doesn't solve the real problem.
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does map it *correctly* to /myapp and forwards it to Tomcat.
It does not IMO, and that's what I'm talking.
Inside mod_jk we should decode
/myapp/%2e%2e/otherapp/danger to
/myapp/../otherapp/danger
No, If the original URI was /myapp/%252e%252e/otherapp/danger, then it
is not correct to end up with /otherapp/danger as a decoded URL.
Yes, but it was already rewritten by apache to
/myapp/%2e%2e/otherapp/danger
If we send that to Tomcat because we mapped to /myapp/*
that it's a security breakage.
A percent sign is a valid character in a ressource path. If one wants to
use it in ressource paths, one needs to encode it ('%25'), and it is not
allowed to decode '%25XX' again after decoding to '%XX' once.
So %252e - %2e and that's it, no further decoding. It is not a '.',
because it is decoded already.
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Because it is on the Tomcat side and it ends up
as /otherapp/danger.
Now, your suggestion would send an faulty uri for
something that shouldn't be passed by the mod_jk at
the first place, because *we know* how the uri will
be decoded on Tomcat.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Bill Barker wrote: Now the reverse proxy should have the ability to modify the URI (in the sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is only able to operate on the decoded URI, we have no chance of making this interoperable with forwarding the original undecoded URI. Yes, RFC 2616 permits *any* intermediate proxy to alter the URI in *any* way before passing it on. So to be meaningful, the Servlet spec requirement can only apply to the URI that TC receives from the last proxy in the chain. Exactly my point. We can rewrite the uri in what ever way we wish as long it is RFC compliant uri. If that means temporary normalizing uri and looking for a malicious requests like /foo/../bar/ what's the problem? We know that this particular request will end up as /bar/ on Tomcat side, so I really see no reason why we shouldn't try to detect that and then if we have JkMount /bar/* we can send as original uri either /bar/ or /foo/../bar/ At the end the Tomcat will serve the same resource. Regards, Mladen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42463] New: - crossContext and classloader issues - pls amend docu
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42463. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42463 Summary: crossContext and classloader issues - pls amend docu Product: Tomcat 6 Version: unspecified Platform: Other URL: http://tomcat.apache.org/tomcat-6.0- doc/config/context.html#Common%20Attributes OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] when discussing sharing data between web-apps, crossContext is always mentioned. interesting hints/threads are: - http://marc.info/?l=tomcat-userm=117615588807658w=2 - http://www.fwd.at/tomcat/sharing-session-data-howto.html Suggestions: 1) In another discussion, Yoav mentions that crossContext is not demanded by any spec and thus not a focus area: if so, are there other approaches to achieve the same? If jndi, clustering, etc. easily achieve the same, pls @deprecate the crossContext and point to those 2) mention that it will not work across all web-apps of a server.xml, but only those within the same engine/host 3) (Haven't tested this entirely) if you plan to share your own (business-)beans, make sure they are not inside each web-app's war, but in $CATALINA_HOME/shared/[lib/*.jar|classes/**/*.class]. Otherwise, despite having built the war's with the same Bean1.class files, the diferent classloaders of the web-apps will cause assigning Bean1 to Bean1 with a ClassCastException 4) e.g. if you want to share e.g. application singleton objects even across hosts/engines (e.g. if your server.xml offers some services under httpS and some under http), it is probably easy to add a class with some static Object fields that will allow to share the singleton even without crossContext -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Apache Tomcat JK 1.2.23 Web Server Connector released
Hi Rainer, Yes, I tried to delete all older versions of binaries (tried = as far as permissions allowed), but for sme platforms we don't have 1.2.23 binares, so I kept the latest available ones. that was what I expected. There is an open point, if we can find a way of distributing contributed builds. I know we could get some, but there were valid concerns, if we shold sign those with our own keys. So we would need some notion of contributed and could put the binaries there. hmm, yes, that's a problem... 4) why do we prefix the directories with 'jk-' although 'jk' is already in the path? No particular reason I am aware of. We just do. Seems to be history, and you decided to drop it for Netware :) that was by acciedent - did rename the directory to be in sync with the others; I thought that some longer time ago we did without, but when I looked through the archives it looked as if we did all the time; so it was merely a question before I checked the archives, and not the wish to change So if the archives are important, we could replace the link text archives... with something a little more prominent. Suggestions? well, thanks to Mark pointing me to the archives I solved this with the README file where I inserted the link to the archive, so all fine for now; and if we find the memory leak with mod_jk AP13 then with 1.2.24 I can again provide binaries for AP13 and NS. thanks, Guen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 41696] - ApplicationDispatcher can't handle alternative HttpRequest-Implementation on forward
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=41696.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41696
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Additional Comments From [EMAIL PROTECTED] 2007-05-20 13:59 ---
This is a feature, done this way exactly to support your use case. The
servlet spec explicitly forbids using a custom ServletRequest that is not
derived from ServletRequestWrapper. For the case with a Wrapper, you simply
need to delay setting up your map:
public String getParameter(String name) {
if(myMap == null) {
loadMap();
}
return (String)myMap.get(name);
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving mod_jk URI forwarding
Why do you think, that /myapp/%252e%252e/otherapp/danger is equivalent to /myapp/../otherapp/danger ? Because it is on the Tomcat side and it ends up as /otherapp/danger. No it is not. If you send /myapp/%252e%252e/otherapp/danger to Tomcat, it will map the URL into the /myapp context (which is correct). Now, your suggestion would send an faulty uri for something that shouldn't be passed by the mod_jk at the first place, because *we know* how the uri will be decoded on Tomcat. Unless we change the AJP connector, there are only three possibilities: - either we iterate over URL decoding unless no more '%' signs are in it - or we deny all URLs with '%25' in them - or we reencode the URL As I understand you, the first two are more what you are about. But this will not allow any requests to be processed, which have a percent character as part of their ressource description. But those URLs are valid! Once again: I think that reencoding and afterwards decoding by Tomcat is the identity operation. So we are in the very god situation, that all mod_jk/httpd logic has been done against the same URL, that will be used by Tomcat. I tried to provide some evidence, why a *decoded* URL of the form /myapp/%2e%2e/otherapp/danger is valid, is unequal to /otherapp/danger and belongs to the /myapp context. Also I showed, why double decoding usually is assumed to be bad practise. Assume there s some content scanning in front of Apache and we double decode, then the same problem will be between the component in front and us. We will end up by simply denying everything with '%25' in it and I find that much more inadequate then reencoding the URL. Why do you think it is a faulty uri and we shouldn't pass it along? Simply reencode and erything is fine. Regards, Rainer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 42412] - java.lang.ClassCastException: javax.mail.Session
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=42412. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=42412 --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 15:18 --- (In reply to comment #1) This works for me with a simple test case. There are, however, some more complex use cases where the jars should only be in common/lib and having the jars in both locations will cause this issue. The information in this report points to an application configuration/deployment issue rather than a Tomcat bug. Yes, this is a configuration issue but, shouldn't Tomcat still function regardless if the .jar files are loaded in two places? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539971 - /tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
Author: billbarker
Date: Sun May 20 15:28:47 2007
New Revision: 539971
URL: http://svn.apache.org/viewvc?view=revrev=539971
Log:
Always reset the MB when doing getBytes
Fix for bug #36155
1) an unconditional reset is cheap if I'm going to call MB.setBytes
2) the JK connector doesn't support any charset except iso-latin-1 anyway
3) This particular connector is on the fast track to deprecated
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java?view=diffrev=539971r1=539970r2=539971
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java Sun May 20
15:28:47 2007
@@ -237,8 +237,8 @@
public void getBytes(MessageBytes mb) {
int length = getInt();
+mb.recycle();
if( (length == 0x) || (length == -1) ) {
-mb.recycle();
return;
}
mb.setBytes( buf, pos, length );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36155] - tomcat chooses wrong host if using mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36155. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36155 --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 15:35 --- I've committed a more general fix for the JK Connector (i.e. JkCoyoteHandler). I can port it to the APR and AJP Connectors if/when Remy and Mladen doen't veto it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r539974 - /tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
Author: billbarker
Date: Sun May 20 15:45:26 2007
New Revision: 539974
URL: http://svn.apache.org/viewvc?view=revrev=539974
Log:
Shave a couple of ms off of the time :)
Modified:
tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
Modified: tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java?view=diffrev=539974r1=539973r2=539974
==
--- tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/jk/common/MsgAjp.java Sun May 20
15:45:26 2007
@@ -237,11 +237,12 @@
public void getBytes(MessageBytes mb) {
int length = getInt();
-mb.recycle();
if( (length == 0x) || (length == -1) ) {
+mb.recycle();
return;
}
mb.setBytes( buf, pos, length );
+mb.getCharChunk().recycle();
pos += length;
pos++; // Skip the terminating \0
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36155] - tomcat chooses wrong host if using mod_jk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36155. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36155 --- Additional Comments From [EMAIL PROTECTED] 2007-05-20 18:30 --- I've committed a more general fix for the JK Connector (i.e. JkCoyoteHandler). I can port it to the APR and AJP Connectors if/when Remy and Mladen doen't veto it. Thanks a lot! I took a look at your commits. I think, the JK Connector is fixed now. I will test it soon. (At the moment, i don't have much time). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
