Security in Tomcat Webapps - WAS: Tomcat 4 / mod_webapp RPMs available...
I send a copy to tomcat-dev since it's an important issue
Thanks for getting back to me so quickly. The distributions you have
provided via jakarta have been very beneficial to us and our
project. We
are grateful so much work has gone into building RPM's.
Thanks ;)
Warning, the RPM goal is to enable people use differents versions,
ie Tomcat 3.3 and Tomcat 4, which are not exclusive and could be
used at the same time. So you need in that case 2 differents home
/var/tomcat3 and /var/tomcat4.
But many users asked me to have TC 3.3 and 4.0 at the same
time on their
boxes to tests applications migration from Servlet 2.2/1.1 to 2.3/1.2
I can see the benefit in this. It's understandable that both platforms
should be capable of running on the same machine. I think you are
correct. I will rebuild our with this put back to tomcat4.
Seems fine to help people determine also which Tomcat they want to use,
it's important for sites which use mod_jk for example which was only
available in TC 3.2/3.3. Also many sites (yes yes) still didn't upgraded
to JDK 1.2, which is mandatory for TC 4.0
We modified the Permissions on the webapps directory to give
tomcat group
users rights to edit files in it, where the
/etc/rc.d/init.d/tomcat script
didn't provide theses permissions previously.
It's bad for security, tomcat shouldn't be allowed to
be able to write these files, only logs and works dirs
Hmm, but your chowning to TOMCAT_USER in your init file does
just that.
The tomcat4 user/group now has full access to the webapps directory
Your code:
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/logs
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/work
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/webapps/*
turns
-rwxrwxrwx1 jcool jcool 6871 Jan 29 15:10 index.html
into
-rwxrwxrwx1 tomcat tomcat 6871 Jan 29 15:10 index.html
And that's bad since index.html should be instead 644 for root:root.
Nota that webapps directory should be writeable by tomcat since
the webapps are decompressed from wxxx.war to wxxx/ in webapps dir.
If a developer places a file in webapps with world read write
permissions then anyone can edit it and tomcat chowns it and
leaves this
permission intact. This means that no security measures are taken to
stop the the tomcat4 group or even the world from really having write
access to these files. In fact chowning the webapps directory gives
tomcat full access to it.
Yes but it shouldn't be writeable, that's a serious security problem.
For example the Apache HTTP server run as nobody or apache user but
all files in htdocs should be writeable only by root.
This is a struggle for us, since the tomcat4 user takes over full user
and group ownership of the webapps directory (without any chmod on the
files within), servlet/jsp developers are then possibly locked out of
having permissions on the files they had originally placed in the
webapps directory. By adding the tomcat4 group to these users and
rewriting tomcat4 rights to write these files we resolved this issue.
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/logs
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/work
chown -R $TOMCAT_USER:$TOMCAT_USER @@@TCHOME@@@/webapps
chmod -R ug+rwx @@@TCHOME@@@/webapps
chmod -R o+xr-w @@@TCHOME@@@/webapps
turns
-rwxrwxrwx1 jcool jcool 6871 Jan 29 15:10 index.html
into
-rwxrwxr-x1 tomcat tomcat 6871 Jan 29 15:10 index.html
In fact the script should be more sofisticated and remove at least
the execute attribute of final files. I'll take a look at it ASAP.
# give access to log subdirs (may be just to tomcat user = chmod 700)
find @@@TCHOME@@@/logs -type d -exec chmod 755 \{\} \;
# only user have write access, all exec removed
find @@@TCHOME@@@/logs -type f -exec chmod 644 \{\} \;
# all files owned by tomcat
find @@@TCHOME@@@/logs -type f -exec chown $TOMCAT_USER:$TOMCAT_USER \{\} \;
# give access to works subdirs (may be just to tomcat user = chmod 700)
find @@@TCHOME@@@/works -type d -exec chmod 755 \{\} \;
# only user have write access, all exec removed
find @@@TCHOME@@@/works -type f -exec chmod 644 \{\} \;
# all files owned by tomcat
find @@@TCHOME@@@/works -type f -exec chown $TOMCAT_USER:$TOMCAT_USER \{\} \;
# give access to webapps subdirs (may be just to tomcat user = chmod 700)
find @@@TCHOME@@@/webapps -type d -exec chmod 755 \{\} \;
# only tomcat have write access, all exec removed
find @@@TCHOME@@@/webapps -type f -exec chmod 644 \{\} \;
# all files owned by tomcat
find @@@TCHOME@@@/webapps -type f -exec chown $TOMCAT_USER:$TOMCAT_USER \{\} \;
I feel you use samba to make webapps dirs writeable to Windows developpers ?
If this is a real problem security-wise. Why does the tomcat4
user have
to own the files in the webapps directory to properly execute them? It
seems that tomcat4 would only require read access.
Exact
Perhaps a better approach would be
RE: [PATCH] RETRY: Tomcat 4.0 Docs SSL-Howto
Seems good to me and should be applied also to Tomcat 3.3 SSL HOWTO :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 11:51 AM To: Tomcat Developers List Subject: Re: [PATCH] RETRY: Tomcat 4.0 Docs SSL-Howto pero wrote: Hi there, I posted this patch a while ago. Noone applied it, so I'm wondering if it is too bad or if you are to busy (somehow I hope the last thing :) I did a new diff against the latest version (see attachment). Any comments are welcome! cheers pero -Original Message- From: pero [mailto:[EMAIL PROTECTED]] Sent: Saturday, December 15, 2001 1:48 AM To: Tomcat Developers List Subject: [PATCH] Tomcat 4.0 Docs SSL-Howto Hi, last summer I posted a step-by-step instruction on how to install a certificate from a certificate authority (such as verisign, thawte...) to both tomcat-4 lists. Until now I got several (partly private) responses regarding this issue and there are questions dealing with that topic on the mailinglist, too. So I decided to contribute my documentation and put it into the ssl-howto.xml found in the webapps/tomcat-docs directory. I hope this patch helps some people out of this partly weird procedure of installing a trusted certificate. I appended a diff -u, which I thought is the standard format you use here (you see, it's my first patch :). I tried to follow all kinds of guidelines I could figure out, but if something's wrong - let me know! If there are any further questions or comments - just hit reply... I like it - If noone complains I will try to commit it - cheers, pero --- - Name: ssl-howto.diff ssl-howto.diffType: diff files (text/plain) Encoding: quoted-printable --- - -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Do different virtual hosts have to have different appBase values?
Dne út 5. únor 2002 01:22 Micael Padraig Og mac Grene napsal(a): [ ] They do. Reason: [ X ] They don't. Reason: It is not necessary. Why to block this functionality? Example: http://www.pig.cz will the same as http://www.pig.net/cz; http://www.pig.net will the same as http://www.pig.cz/en; Using request.getServletPath) and request.getRequestURI() I shoul recognize the default language of the application and the different languages should share whole application including servlet mappings in web.xml. Why not? But for example http://www.pig.cz/monkey should not be configured and http://www.pig.net/monkey should. Why not? If the Tomcat should run only on Operating Systems, it will be good and sharing of the appBase is not necessary, because OS supports symlinks. But file systems of the Disk Operating Systems doesn't support symlinks well known from UNIX, so the sharing is only the solution for this. -- Oto 'tapik' Buchta -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6214] - Problems on ClientAuth
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=6214. 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=6214 Problems on ClientAuth --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 09:34 --- I think I've found the problem! Tomcat 3.2.4 use clientAuth (with capitalized A). Tomcat 3.3a use clientauth (with lowercase a) but... in tomcat-ssl-howto.html di tomcat3.3a, chapter SSL Standalone, paragraph 3 Edit the Tomcat configuration file appears this syntax for tomcat 3.3: Http10Connector port=8443 clientAuth=false / ... with capitalized A again. So what's wrong: CODE or DOC ??? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt
-Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 06:44 To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat RELEASE-PLAN-3.3.1.txt Issue Description 1 Must be able to compile and run under JDK 1.1.8 + FIXED 2 Address Cactus failures running with Tomcat 3.3 + Tried but not 100% successful yet. From what little I've seen, I've never really understood this one. The so we're 2 ;-). What I don't understand is why Cactus tests run fine on all servlet containers (including Tomcat 3.2.x and Tomcat 4.x) except for Tomcat 3.3.x ! Request runs under a single thread, so yielding shouldn't do anything at all (unless the Cactus servlet starts a thread, in which case it is a Cactus problem). Cactus is not starting any thread. I can see where increasing SoLinger might help, but 0.1 Sec should be plenty with an up-to-date machine. Does the problem appear when you don't use the HTTP connector? How could I test this as I need to HTTP connector to call the Cactus servlet ? Thanks Bill, -Vincent -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4212] - How to configure Apache to serve static contents?
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=4212. 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=4212 How to configure Apache to serve static contents? --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 10:02 --- I have tried to do this with Apache 1.3.22 and Tomcat 4.0.2-b2 but it still doesn't work. When I call my application directly from tomcat i have no problems but if I pass throught Apache (same URL whithout prot 8080), my JSP and servlet responds well but every JPG and GIF files doesn't appears and Apache seems to be K.O. Is that the troubles you encounter ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6244] New: - javax.servlet.* in WEB-INF/lib overrides containers version
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=6244. 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=6244 javax.servlet.* in WEB-INF/lib overrides containers version Summary: javax.servlet.* in WEB-INF/lib overrides containers version Product: Tomcat 4 Version: 4.0 Beta 1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] During development we have placed a copy of the 2.2 spec javax.servlet.* classes into our WEB-INF/lib directory of our webapp to make compilation easy. With Tomcat4 though, when compiling a JSP page, we get an error due to Jasper using our 2.2 version rather than the containers 2.3 version of javax.servlet.jsp.tagext.BodyTag (the static EVAL_BODY_BUFFERED is new to BodyTag in 2.3). I believe this to be contrary to the 2.3 spec, section SRV 9.7.2, which says that the classloader the container provides a webapp must not allow a WAR to override J2SE or Java servlet API classes. The workaround is not to place the 2.2 classes in the webapp! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6244] - javax.servlet.* in WEB-INF/lib overrides containers version
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=6244. 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=6244 javax.servlet.* in WEB-INF/lib overrides containers version [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 12:51 --- That requirement is easier said than done, since the complete list of the shared APIs is a moving target (and is huge). Also, given the way Java compilation tech works, it's impossible to implement correctly with Jasper. That being said, the HEAD branch uses a few very specific tricks, and does what you want. The fix will not be ported to the 4.0.x however, as it's too experimental. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6213] - Apache, Tomcat 4 mod_jk.
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=6213. 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=6213 Apache, Tomcat 4 mod_jk. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 12:52 --- Read the docs ! Post on tomcat-user for help / info. Thanks ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6211] - bug with jsp:plugin
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=6211. 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=6211 bug with jsp:plugin [EMAIL PROTECTED] changed: What|Removed |Added Component|Unknown |Jasper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6208] - Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface
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=6208. 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=6208 Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 12:59 --- Send redirect doesn't really do that (look at the javadocs). Instead, set the header and the status code yourself, and it should work. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6247] New: - Tomcat not referencing jar files in web-inf/lib classpath conflicts
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=6247. 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=6247 Tomcat not referencing jar files in web-inf/lib classpath conflicts Summary: Tomcat not referencing jar files in web-inf/lib classpath conflicts Product: Tomcat 4 Version: 4.0 Beta 1 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Webapps AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have deployed a webapp under tomcat 4.0, through a .war file. tomcat explodes the war properly, and i am able to access my jsp's and static documents etc. my servlets use other classes i have written, so accordingly i packaged them in to a jar and placed them in the web-inf/lib (when i was creating the .war) - but Tomcat doesnt seem to look here and reports that it cant find the classes. But - when I add the location of those external classes to my system classpath, and re-start Tomcat, it can see those classes and things seem to work fine - but, now there is a conflict since, tomcat references other classes in that location and that causes problems with my servlets. i dont know if you will be able to reproduce this, or if it is a bug in the first place - but i really have a straightforward set up, and cant see the problem. thanks, deepak -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat 3.3 - Cactus Issue
Hi Bill, Here are the details of the problem with Tomcat 3.3 and Cactus. Apparently, Cactus's sample test suite run against Tomcat 3.3 will occasionally fail on the main Gump system (a 300Mhz system running Linux) and reliably fails Vincent Massol's laptop (1Gig+ system running Windows XP). The failure is the same for both. In the testPostMethod test, the following exception is thrown on by the Cactus client: java.net.SocketException: Connection aborted by peer: JVM_recv in socket input stream read at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) at java.io.BufferedInputStream.read1(BufferedInputStream.java:225) at java.io.BufferedInputStream.read(BufferedInputStream.java:280) at java.io.FilterInputStream.read(FilterInputStream.java:114) at java.io.PushbackInputStream.read(PushbackInputStream.java:164) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:649) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:613) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:621) at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:506) at org.apache.cactus.client.AutoReadHttpURLConnection.getInputStream (AutoReadHttpURLConnection.java; org/apache/cactus/util/log/LogAspect.java(1k):123) at org.apache.cactus.client.AbstractHttpClient.callRunTest (AbstractHttpClient.java; org/apache/cactus/util/log/LogAspect.java(1k):192) at org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround10 (AbstractHttpClient.java; org/apache/cactus/util/log/LogAspect.java(1k):119) at org.apache.cactus.client.AbstractHttpClient.doTest (AbstractHttpClient.java; org/apache/cactus/util/log/LogAspect.java(1k):1204) at org.apache.cactus.AbstractTestCase.runGenericTest (AbstractTestCase.java:437) at org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:130) at org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:385) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:131) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run (JUnitTestRunner.java:231) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main (JUnitTestRunner.java:409) I have read in Microsoft documentation that it is possible for the sending end of a socket to be closed before the receiving end retrieves all of the data. The receiving end can get a socket is closed error (I forget the symbol) and not be able to retrieve all of the data. I was able to see this in action when working on the Jserv connector a while ago. The client socket was busy trying to send some post data that wasn't going to be read. When Tomcat, 3.2.x in this case, closed the socket at the end of handling the POST request, the client received an error and wasn't able to read the response. I believe the form of error that occurs is one that leads to the Connection aborted by peer as seen above. My assumption is that the same kind of thing is happening to Cactus, but in a simpler situation. The Tomcat side shows no errors occurring. Inspecting source for sun.net.www.http.HttpClient, the exception is occuring while it is trying to read the HTTP/... at the beginning of the response. The testPostMethod is executed by a controller servlet, but as far as I can tell, no POST data is sent and a minimal response is returned. Introducing a sleep(0) on the Tomcat side just before the socket.close() appeared to fix the problem on Vincent's laptop. My assumption is that this forces the Tomcat thread to yield and give the client thread a chance to receive the response before the socket gets closed. Unfortunately, this sleep(0) causes the failure on Gump to go from infrequent to frequent. My second round of kluging didn't help, so I reverted to the sleep(0) last night. I know very little about *nix internal operation and can't explain why sleep(0) causes harm. On my RH Linux 7.1 at home, I'm not able to get sleep(0) to cause the Cactus failure, but sleep(1) consistently does. I assume the threading of Linux sockets is just different from the way it is handled on Windows. Unfortunately I am unable to duplicate this failure on my Windows system as it is a measly 500Mhz PIII. I don't see that Tomcat 3.3 is
Re:Connectors, Realms, 4.0.2b2 - 403 Access Denied
I'm posting this question a second time since I am not sure if mailer problems on my end prevented it from reaching the list and I got no responses on the issue. The security implementation in Tomcat 4.0.2b2 and earlier seems to depend on using redirect urls. This doesn't seem to work correctly with connectors such as the IISAPI IIS connector. What is the strategy for supporting basic or form based authentication through connectors? Should this be implemented without using redirect? I've configured Tomcat4.0.2b2 with the AJP 1.3 Connector and successfully installed the iisapi dll from Tomcat3.3 into IIS. I am attempting to serve a protected page through the connector using the protected realm example. When I hit the page directly on port 8080, I get the expected login form challenge behavior. When I hit the page through the connector, I get a 403 access denied error. Is serving protected pages through connectors supposed to be supported in 4.0.2? http://localhost:8080/examples/jsp/security/protected/index.jsp redirects to the login screen as expected. http://localhost/examples/jsp/security/protected/index.jsp returns 403 - Access to the requested resource has been denied -Jonathan * This email and any files transmitted with it are for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. This email message has been swept by a virus software product for the presence of computer viruses. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6248] - using xerces in webapp causes class cast exception
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=6248. 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=6248 using xerces in webapp causes class cast exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-02-05 15:33 --- That indeed won't work, especially the combo Xerces 1 + Xerces 2. The HEAD branch of Tomcat fixes it, but since it's a classloader change, it may not be ported to the 4.0.x branch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug in safe url parsing
Greetings,
There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing. That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.
So, when safe url checks for indexOf('%'), depending on the
length of the method name, a number of %'s at the beginning
of the URL may be missed.
So, the following URLs would be tagged as safe (currently):
GET /wannamak/%25%5C
A quick fix is to use indexOf(%), which converts the
relevant part of the byte array to a string, so the offset
is correct.
However, I think that it would be better to correct BC.indexOf
in the following manner:
Index: ByteChunk.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChun
k.java,v
retrieving revision 1.8
diff -u -r1.8 ByteChunk.java
--- ByteChunk.java 19 Jul 2001 05:49:02 - 1.8
+++ ByteChunk.java 5 Feb 2002 17:36:42 -
@@ -626,7 +626,8 @@
* @param s the string
*/
public int indexOf(char c, int starting) {
- return indexOf( buff, start+starting, end, c);
+ int ret = indexOf( buff, start+starting, end, c);
+ return (ret = start) ? ret - start : -1;
}
public static int indexOf( byte bytes[], int off, int end, char qq )
I will commit this later today if I hear no objection.
Regards,
Keith
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 - Cactus Issue
Hi Larry,
We had a similar problem long time ago - with the POST and the extra
CRLF. While investigating it, I found a lot of interesting stuff
about Connection reset by peer :-)
Most of the time it happens when something is still in the write
buffer ( i.e. unsent or unread ), and the remote side is closing
the connection.
This is the correct behavior, as it signal the sending side that
whatever it has in the send buffers will be lost. It will
happen if tomcat doesn't receive the full POST data - it used
to be the extra CRLF that some browsers sent ( above
the Content-Length limit ).
The first thing I would check is if the full body was read -
we already have the workaround for the CRLF bug in TcpConnection,
but it is possible something is wrong there.
Looking at the code, it may be possible that after
while( available 0 ) { is.skip(), available=is.availabe() }
we may receive some more data.
That's likely to happen on a fast system, and a sleep before
close() would make it more likely.
The code was supposed to deal with 2 bytes of extra data ( the
CRLF ), not with some POST body that is supposed to be ignored,
so it isn't implementing a 'correct' socket.shutdownInput().
One thing to try is to use the JDK1.3 socket.shutdownInput()
instead ( with a Jdk11Compat workwaround ).
I see no good way to implement this - doesn't matter what
we do, between reading/skiping data that is available and
calling close() it is allwasy possible we'll receive more
data ( we can't 'sync' or anything like that ). It is likely
the threading model affects that - probably is.available()
call yields on some OSes, giving the sender an extra chance to
send more data.
A solution would be to read/ignore the full post body - but that
is very bad in case of large bodies ( that the servlet may
decide to ignore ), and for DOS.
Let me know if that helps - and if not what's the easiest way
to reproduce ( I don't use Windows, but I can find a system
with W2000, not sure about XP )
Costin
On Tue, 5 Feb 2002, Larry Isaacs wrote:
Hi Bill,
Here are the details of the problem with Tomcat 3.3 and Cactus.
Apparently, Cactus's sample test suite run against Tomcat 3.3 will
occasionally fail on the main Gump system (a 300Mhz system running
Linux) and reliably fails Vincent Massol's laptop (1Gig+ system
running Windows XP). The failure is the same for both. In the
testPostMethod test, the following exception is thrown on by the
Cactus client:
java.net.SocketException: Connection aborted by peer: JVM_recv in
socket input stream read
at java.net.SocketInputStream.socketRead(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:86)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:225)
at java.io.BufferedInputStream.read(BufferedInputStream.java:280)
at java.io.FilterInputStream.read(FilterInputStream.java:114)
at java.io.PushbackInputStream.read(PushbackInputStream.java:164)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:649)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:613)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:621)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:506)
at org.apache.cactus.client.AutoReadHttpURLConnection.getInputStream
(AutoReadHttpURLConnection.java;
org/apache/cactus/util/log/LogAspect.java(1k):123)
at org.apache.cactus.client.AbstractHttpClient.callRunTest
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):192)
at org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround10
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):119)
at org.apache.cactus.client.AbstractHttpClient.doTest
(AbstractHttpClient.java;
org/apache/cactus/util/log/LogAspect.java(1k):1204)
at org.apache.cactus.AbstractTestCase.runGenericTest
(AbstractTestCase.java:437)
at org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:130)
at org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:385)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:131)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at junit.framework.TestSuite.runTest(TestSuite.java:173)
at junit.framework.TestSuite.run(TestSuite.java:168)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run
(JUnitTestRunner.java:231)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main
cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.bat
patrickl02/02/05 09:59:28 Modified:catalina/src/bin setclasspath.bat Log: Add checking for all of the other tools in JAVA_HOME that the other scripts use Revision ChangesPath 1.3 +10 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat Index: setclasspath.bat === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.bat,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- setclasspath.bat 30 Jan 2002 23:01:50 - 1.2 +++ setclasspath.bat 5 Feb 2002 17:59:28 - 1.3 @@ -1,7 +1,7 @@ rem --- rem Set CLASSPATH and Java options rem -rem $Id: setclasspath.bat,v 1.2 2002/01/30 23:01:50 patrickl Exp $ +rem $Id: setclasspath.bat,v 1.3 2002/02/05 17:59:28 patrickl Exp $ rem --- rem Make sure prerequisite environment variables are set @@ -10,7 +10,12 @@ echo This environment variable is needed to run this program goto end :gotJavaHome -if exist %JAVA_HOME%\bin\java.exe goto okJavaHome +if not exist %JAVA_HOME%\bin\java.exe goto noJavaHome +if not exist %JAVA_HOME%\bin\javaw.exe goto noJavaHome +if not exist %JAVA_HOME%\bin\jdb.exe goto noJavaHome +if not exist %JAVA_HOME%\bin\javac.exe goto noJavaHome +goto okJavaHome +:noJavaHome echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program goto end @@ -44,3 +49,6 @@ set _RUNJAVA=%JAVA_HOME%\bin\java set _RUNJAVAW=%JAVA_HOME%\bin\javaw set _RUNJDB=%JAVA_HOME%\bin\jdb +set _RUNJAVAC=%JAVA_HOME%\bin\javac + +:end -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/bin setclasspath.sh
patrickl02/02/05 10:00:20 Modified:catalina/src/bin setclasspath.sh Log: Add checking for all of the other tools in JAVA_HOME that the other scripts use Revision ChangesPath 1.3 +3 -2 jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh Index: setclasspath.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/setclasspath.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- setclasspath.sh 30 Jan 2002 23:01:50 - 1.2 +++ setclasspath.sh 5 Feb 2002 18:00:20 - 1.3 @@ -1,7 +1,7 @@ # - # Set CLASSPATH and Java options # -# $Id: setclasspath.sh,v 1.2 2002/01/30 23:01:50 patrickl Exp $ +# $Id: setclasspath.sh,v 1.3 2002/02/05 18:00:20 patrickl Exp $ # - # Make sure prerequisite environment variables are set @@ -10,7 +10,7 @@ echo This environment variable is needed to run this program exit 1 fi -if [ ! -r $JAVA_HOME/bin/java ]; then +if [ ! -r $JAVA_HOME/bin/java -o ! -r $JAVA_HOME/bin/jdb -o ! -r $JAVA_HOME/bin/javac ]; then echo The JAVA_HOME environment variable is not defined correctly echo This environment variable is needed to run this program exit 1 @@ -49,3 +49,4 @@ # Set standard commands for invoking Java. _RUNJAVA=$JAVA_HOME/bin/java _RUNJDB=$JAVA_HOME/bin/jdb +_RUNJAVAC=$JAVA_HOME/bin/javac -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Comments below.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:45 PM
To: Tomcat Developers List
Subject: Re: Tomcat 3.3 - Cactus Issue
Hi Larry,
We had a similar problem long time ago - with the POST and the extra
CRLF. While investigating it, I found a lot of interesting stuff
about Connection reset by peer :-)
The best I can tell, no POST data is sent and none is read, so I
have been assuming this isn't the problem.
Most of the time it happens when something is still in the write
buffer ( i.e. unsent or unread ), and the remote side is closing
the connection.
This is the correct behavior, as it signal the sending side that
whatever it has in the send buffers will be lost. It will
happen if tomcat doesn't receive the full POST data - it used
to be the extra CRLF that some browsers sent ( above
the Content-Length limit ).
The first thing I would check is if the full body was read -
we already have the workaround for the CRLF bug in TcpConnection,
but it is possible something is wrong there.
Looking at the code, it may be possible that after
while( available 0 ) { is.skip(), available=is.availabe() }
we may receive some more data.
I believe this code is newer than the last official failure
I heard of from Vincent. I think this was:
if (available 1) {
is.skip (available);
}
prior to Bill's recent commit to TcpConnection.java.
That's likely to happen on a fast system, and a sleep before
close() would make it more likely.
The code was supposed to deal with 2 bytes of extra data ( the
CRLF ), not with some POST body that is supposed to be ignored,
so it isn't implementing a 'correct' socket.shutdownInput().
One thing to try is to use the JDK1.3 socket.shutdownInput()
instead ( with a Jdk11Compat workwaround ).
I see no good way to implement this - doesn't matter what
we do, between reading/skiping data that is available and
calling close() it is allwasy possible we'll receive more
data ( we can't 'sync' or anything like that ). It is likely
the threading model affects that - probably is.available()
call yields on some OSes, giving the sender an extra chance to
send more data.
A solution would be to read/ignore the full post body - but that
is very bad in case of large bodies ( that the servlet may
decide to ignore ), and for DOS.
Let me know if that helps - and if not what's the easiest way
to reproduce ( I don't use Windows, but I can find a system
with W2000, not sure about XP )
I'll see if I can verify if there is any extra input coming
from the client.
To reproduce, I get the Cactus source and with appropriate
build.properties files, I build the clean, jar, and sample
targets. I then create/copy a build.properties file to the
../target/servlet22/dist/sample/build and run the
tests_tomcat_33 target. There are some additional jars to
add to Ant's lib directory, but I don't have that list off
the top of my head. Let me know if you need any additional
specifics.
Cheers,
Larry
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002 [EMAIL PROTECTED] wrote: Most of the time it happens when something is still in the write buffer ( i.e. unsent or unread ), and the remote side is closing the connection. I'll try again: Assuming CLIENT sending data to SERVER. The exception happens when: - server has received some data from client ( so client believes the data reached the destionation ). The data is in some OS buffer. - server dies or close() the socket, without reading the data from the OS buffer - some OSes have a TCP implementation that does what I believe to be right - send an ABORT ( instead of the regular CLOSE ). - the client will receive the ABORT and throw the exception ( that coresponds to SIGPIPE if the same thing would be done locally ) ( it seems my original mail was not very clear ). My feeling is that we are exaclty in this case - the logic to close the socket is trying to read the remaining data from the available() buffer ( impl. of the fix for extra CRLF bug ), but the impl is likely to fail on a fast OS or on certain threading models where the CLIENT may send aditional data between we read the input buffer and close(). Vincent: is your test servlet reading the body i.e. calls getParameters() if it's a url-encoded body, or read the full stream ? If not, I believe the current behavior is correct and shouldn't be changed - it signals the CLIENT that whatever it posted was not read, and that's a very usefull information we shouldn't hide. If this is not the case, and the servlet has read the body - than it's a serious problem. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Vincent: is your test servlet reading the body i.e. calls getParameters() if it's a url-encoded body, or read the full stream ? If not, I believe the current behavior is correct and shouldn't be changed - it signals the CLIENT that whatever it posted was not read, and that's a very usefull information we shouldn't hide. If this is not the case, and the servlet has read the body - than it's a serious problem. I looked for this and didn't find that there was any POST data sent and none was read. I certainly could have missed something. I don't completely understand everything that Cactus' controller servlet does on the Tomcat side. However, I think I checked to see what is.available() was reporting, in TcpConnector, and believe it was zero during Windows runs which never failed for me. If extra unread characters are present, this shouldn't be zero if the test succeeds. Or am I still missing something? I'll try to check again. Cheers, Larry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
Larry, See below. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: 05 February 2002 19:03 To: 'Tomcat Developers List' Subject: RE: Tomcat 3.3 - Cactus Issue Comments below. [snip] Let me know if that helps - and if not what's the easiest way to reproduce ( I don't use Windows, but I can find a system with W2000, not sure about XP ) I'll see if I can verify if there is any extra input coming from the client. To reproduce, I get the Cactus source and with appropriate build.properties files, I build the clean, jar, and sample targets. I then create/copy a build.properties file to the ../target/servlet22/dist/sample/build and run the tests_tomcat_33 target. There are some additional jars to add to Ant's lib directory, but I don't have that list off the top of my head. Let me know if you need any additional specifics. To run the Cactus tests, the simplest is to : - create a build.properties file in build/ (you can use the build.properties.sample as a template). Make sure you define tomcat.home.33 - simply type 'ant tests' That's all. Cheers, Larry thanks -Vincent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002, Larry Isaacs wrote: I looked for this and didn't find that there was any POST data sent and none was read. I certainly could have missed something. I don't completely understand everything that Cactus' controller servlet does on the Tomcat side. However, I think I checked to see what is.available() was reporting, in TcpConnector, and believe it was zero during Windows runs which never failed for me. If extra unread characters are present, this shouldn't be zero if the test succeeds. Or am I still missing something? I'll try to check again. On linux, you may be able to do a tcpdump and look for ABORTs, that would be a good sign we're in this particular case. An intersting note is that different impl. of TCP send or not the ABORT - even for the same OS. I never understood why ( it may even be settable somewhere ) - the spec seems to require it. One question - with the sleep(), do you do an isAvailable()/skip() after the sleep ? One easy thing to check is to do a Request.getContentLength() and check Request.available ( it should be the length of the unread body ). I'll try to reproduce it and check this. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Development Documents
Hi! I'm thinking of a web application that processes JSP itself and returns only the HTML content of JSP pages back to the Client. I don't want to point the Client to Java Server Pages. Where can I find usefull documentation to evaluate such a functionality for Tomcat? Have you any suggestions for me? Thanks, Gunnar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 2:46 PM To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Tue, 5 Feb 2002, Larry Isaacs wrote: One question - with the sleep(), do you do an isAvailable()/skip() after the sleep ? Didn't try is.available() after the sleep. I can try that. Larry -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: PageCaching Feature
-Original Message- From: Gunnar Wagenknecht Sent: Tuesday, February 05, 2002 8:43 PM To: 'Tomcat Developers List' Subject: RE: PageCaching Feature Hi! I'm sorry but OSCache is not that what I really need. I want to cache the full output of selected URLs not just JSP. Any Ideas? I plan to build a web application with a CentralEntryServlet. This Servlet invokes some actions which depends on the given PathInfo. The actions are very extensive and return a ready OutputStream which then is printed out to the Client. Cu, Gunnar -Original Message- From: Deacon Marcus [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 03, 2002 3:14 PM To: Tomcat Developers List Subject: RE: PageCaching Feature Hi, Check http://www.opensymphony.com/oscache/ , you may find it interesting. Greetings, deacon Marcus -Original Message- From: Gunnar Wagenknecht [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 03, 2002 2:46 PM To: [EMAIL PROTECTED] Subject: PageCaching Feature Hi! I'm wondering if it is possible to implement a page chaching mechanisme into the Tomcat Engine? Did anyone thought about this before? Where can I find suitable development documents to evalutate the implementation of such a functionality into the Tomcat Engine? I currently evaluating and working on some proposals for an extensive web application. To speed up performance and to reduce the load it would be great to add a HTML comment tag (for example: !-- PAGECACHE created=datetimestamp expires=hours:minutes --) to the HTML Output Stream. It is not crucial whether this tag was inserted into a JSP or by a Servlet. Tomcat than realizes that it should cache this result that was returned by calling the specific URL and safes the complete HTML output stream into a file on the disc. Next time this URL is retrieved Tomcat first looks, if there is a cached page available and if this page is not obsolete. If there is a valid cached page, Tomcat doesn't need to call the WebApplication instead Tomcat can return the result immediatly. Of curse the evalutation of the URL is not simple because you have to look for URL path and parameter and it should pe possible to tell the page caching mechanisme which URL parameters a sensible and which it should ignor. What do you guys think of this? I'm not an experienced developer that's why I'm asking you where I can start. What do you expect about the complexity (development/implementation time) of such a feature? Until today I only saw solutions with an adapter application between the webserver and the web applcation. But this adapter application has to be developed for every webserver API which you want to support. But I plan to access Tomcat directly and not over a web server. Cu, Gunnar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Development Documents
Hi, Gunnar. I think that this is what JSP itself does already, i.e. return HTML content. So, I am not sure what you are asking. If you don't want to use JSP pages, then don't. I am sure that is not what you wanted to say, so, again, I misunderstood what you are saying. Could you be more specific about what you want? You don' t have to use JSP pages with Tomcat, but then there would be no point in having Tomcat really. At 08:50 PM 2/5/02 +0100, you wrote: Hi! I'm thinking of a web application that processes JSP itself and returns only the HTML content of JSP pages back to the Client. I don't want to point the Client to Java Server Pages. Where can I find usefull documentation to evaluate such a functionality for Tomcat? Have you any suggestions for me? Thanks, Gunnar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Bug in safe url parsing
This looks good to me. Also, CharChunk looks like it has
the same problem. Could you go ahead and fix that
on as well. Thanks.
Cheers,
Larry
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:45 PM
To: Tomcat Developers List
Cc: [EMAIL PROTECTED]
Subject: Bug in safe url parsing
Greetings,
There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing. That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.
So, when safe url checks for indexOf('%'), depending on the
length of the method name, a number of %'s at the beginning
of the URL may be missed.
So, the following URLs would be tagged as safe (currently):
GET /wannamak/%25%5C
A quick fix is to use indexOf(%), which converts the
relevant part of the byte array to a string, so the offset
is correct.
However, I think that it would be better to correct BC.indexOf
in the following manner:
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChun
k.java,v
retrieving revision 1.8
diff -u -r1.8 ByteChunk.java
--- ByteChunk.java 19 Jul 2001 05:49:02 - 1.8
+++ ByteChunk.java 5 Feb 2002 17:36:42 -
@@ -626,7 +626,8 @@
* @param s the string
*/
public int indexOf(char c, int starting) {
- return indexOf( buff, start+starting, end, c);
+ int ret = indexOf( buff, start+starting, end, c);
+ return (ret = start) ? ret - start : -1;
}
public static int indexOf( byte bytes[], int off, int
end, char qq )
I will commit this later today if I hear no objection.
Regards,
Keith
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PageCaching Feature
Hi! I'm sorry but OSCache is not that what I really need. I want to cache the full output of selected URLs not just JSP. Any Ideas? I plan to build a web application with a CentralEntryServlet. This Servlet invokes some actions which depends on the given PathInfo. The actions are very extensive and return a ready OutputStream which then is printed out to the Client. Cu, Gunnar -Original Message- From: Deacon Marcus [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 03, 2002 3:14 PM To: Tomcat Developers List Subject: RE: PageCaching Feature Hi, Check http://www.opensymphony.com/oscache/ , you may find it interesting. Greetings, deacon Marcus -Original Message- From: Gunnar Wagenknecht [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 03, 2002 2:46 PM To: [EMAIL PROTECTED] Subject: PageCaching Feature Hi! I'm wondering if it is possible to implement a page chaching mechanisme into the Tomcat Engine? Did anyone thought about this before? Where can I find suitable development documents to evalutate the implementation of such a functionality into the Tomcat Engine? I currently evaluating and working on some proposals for an extensive web application. To speed up performance and to reduce the load it would be great to add a HTML comment tag (for example: !-- PAGECACHE created=datetimestamp expires=hours:minutes --) to the HTML Output Stream. It is not crucial whether this tag was inserted into a JSP or by a Servlet. Tomcat than realizes that it should cache this result that was returned by calling the specific URL and safes the complete HTML output stream into a file on the disc. Next time this URL is retrieved Tomcat first looks, if there is a cached page available and if this page is not obsolete. If there is a valid cached page, Tomcat doesn't need to call the WebApplication instead Tomcat can return the result immediatly. Of curse the evalutation of the URL is not simple because you have to look for URL path and parameter and it should pe possible to tell the page caching mechanisme which URL parameters a sensible and which it should ignor. What do you guys think of this? I'm not an experienced developer that's why I'm asking you where I can start. What do you expect about the complexity (development/implementation time) of such a feature? Until today I only saw solutions with an adapter application between the webserver and the web applcation. But this adapter application has to be developed for every webserver API which you want to support. But I plan to access Tomcat directly and not over a web server. Cu, Gunnar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Development Documents
Hi! I plan to build a web application with a CentralEntryServlet. This Servlet invokes some actions which depends on the given PathInfo. The actions are very extensive and return a ready OutputStream which then is printed out to the Client. I want to use templates which are connected to different actions. The actions aren't provided with the web application. They depend on the needs of a customer. You can think of these actions were like a list of modules which collects/prepare some data and the templates to show these data. One possibility would be to point the Client to a JSP page after processing the actions and then let Tomcat do the rest. But I don't like this possibility. The templates should be thin with no java source inside. I want to reduce and to simplify the template development drastically so I don't want the Web designers to use JSP tags inside these templates. Instead the templates have only a few more TAGs additionaly to HTML. These tags are converted to Java source by the template compiler of my application so that the compiled templated is a JSP. Now I want this JSP be processed to get the HTML output which I can then print out to the client. Cu, Gunnar -Original Message- From: Micael Padraig Og mac Grene [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 8:46 PM To: Tomcat Developers List Subject: Re: Development Documents Hi, Gunnar. I think that this is what JSP itself does already, i.e. return HTML content. So, I am not sure what you are asking. If you don't want to use JSP pages, then don't. I am sure that is not what you wanted to say, so, again, I misunderstood what you are saying. Could you be more specific about what you want? You don' t have to use JSP pages with Tomcat, but then there would be no point in having Tomcat really. At 08:50 PM 2/5/02 +0100, you wrote: Hi! I'm thinking of a web application that processes JSP itself and returns only the HTML content of JSP pages back to the Client. I don't want to point the Client to Java Server Pages. Where can I find usefull documentation to evaluate such a functionality for Tomcat? Have you any suggestions for me? Thanks, Gunnar -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
I tried adding a Thread.sleep(1) just before the call to TcpConnection.shutdownInput() in Http10Interceptor. A System.out.println() within shutdownInput's while never prints during a successful Cactus run on Win2k. Is there anything different I should try? Larry -Original Message- From: Larry Isaacs Sent: Tue 2/5/2002 2:56 PM To: 'Tomcat Developers List' Cc: Subject: RE: Tomcat 3.3 - Cactus Issue -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 05, 2002 2:46 PM To: Tomcat Developers List Subject: RE: Tomcat 3.3 - Cactus Issue On Tue, 5 Feb 2002, Larry Isaacs wrote: One question - with the sleep(), do you do an isAvailable()/skip() after the sleep ? Didn't try is.available() after the sleep. I can try that. Larry msg21385/bin0.bin Description: application/ms-tnef -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat 3.3 - Cactus Issue
On Tue, 5 Feb 2002, Larry Isaacs wrote: I tried adding a Thread.sleep(1) just before the call to TcpConnection.shutdownInput() in Http10Interceptor. A System.out.println() within shutdownInput's while never prints during a successful Cactus run on Win2k. Is there anything different I should try? It seems I was wrong, it may be a different problem. I'll try to reproduce it. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6260] New: - No processor available, rejecting this connection
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=6260. 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=6260 No processor available, rejecting this connection Summary: No processor available, rejecting this connection Product: Tomcat 4 Version: 4.0.2 Beta 2 Platform: Other OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] No processor available, rejecting this connection occured always after new server threads started. I use tomcat with Jboss on a double 1G cpu, 1G mem pc, there were about 10 users to access at the same time. error log listed below: [08:45:02,375,Default] at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source) [08:45:02,375,Default] [08:45:02,375,Default] at java.lang.Thread.run(Unknown Source) [08:45:02,375,Default] [08:46:33,453,EmbeddedCatalinaServiceSX] HttpProcessor[8080][16] Starting background thread [08:46:35,812,EmbeddedCatalinaServiceSX] HttpProcessor[8080][17] Starting background thread [08:46:41,343,EmbeddedCatalinaServiceSX] HttpProcessor[8080][18] Starting background thread [08:47:12,921,EmbeddedCatalinaServiceSX] HttpProcessor[8080][19] Starting background thread [08:47:12,937,EmbeddedCatalinaServiceSX] HttpConnector[8080] No processor available, rejecting this connection ilable, rejecting this connection [08:58:24,578,EmbeddedCatalinaServiceSX] HttpConnector[8080] No processor available, rejecting this connection [08:58:28,265,EmbeddedCatalinaServiceSX] HttpConnector[8080] No processor available, rejecting this connection [09:00:01,156,EmbeddedCatalinaServiceSX] HttpConnector[8080] No processor available, rejecting this connection [INFO,J2eeDeployer] Stopping module bsWAR.war [INFO,EmbeddedCatalinaServiceSX] StandardHost[localhost]: Removing web application at cont ext path /bizsphere [INFO,EmbeddedCatalinaServiceSX] StandardWrapper[/bizsphere:jsp]: Waiting for 1 instance(s ) to be deallocated [09:00:11,765,EmbeddedCatalinaServiceS -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Bug in safe url parsing
On Tue, 5 Feb 2002, Larry Isaacs wrote:
This looks good to me. Also, CharChunk looks like it has
the same problem. Could you go ahead and fix that
on as well. Thanks.
And please, update j-t-c/util package as well :-)
Costin
-Original Message-
From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 05, 2002 12:45 PM
To: Tomcat Developers List
Cc: [EMAIL PROTECTED]
Subject: Bug in safe url parsing
Greetings,
There is a bug in ByteChunk.indexOf which manifests itself
in the safe url parsing. That is, BC.indexOf returns an
offset relative to the start of the byte buffer, rather
than the internal starting point.
So, when safe url checks for indexOf('%'), depending on the
length of the method name, a number of %'s at the beginning
of the URL may be missed.
So, the following URLs would be tagged as safe (currently):
GET /wannamak/%25%5C
A quick fix is to use indexOf(%), which converts the
relevant part of the byte array to a string, so the offset
is correct.
However, I think that it would be better to correct BC.indexOf
in the following manner:
Index: ByteChunk.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/buf/ByteChun
k.java,v
retrieving revision 1.8
diff -u -r1.8 ByteChunk.java
--- ByteChunk.java 19 Jul 2001 05:49:02 - 1.8
+++ ByteChunk.java 5 Feb 2002 17:36:42 -
@@ -626,7 +626,8 @@
* @param s the string
*/
public int indexOf(char c, int starting) {
- return indexOf( buff, start+starting, end, c);
+ int ret = indexOf( buff, start+starting, end, c);
+ return (ret = start) ? ret - start : -1;
}
public static int indexOf( byte bytes[], int off, int
end, char qq )
I will commit this later today if I hear no objection.
Regards,
Keith
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
patch: fix warp connector to properly implement flush() and flushBuffer()
Hi all,
I've got a little servlet that keeps the HTTP connection streams data (html
script data, to be precise) at the rate of a few bytes per second. Tomcat
handled this fine, but as soon as I routed it through Apache using the warp
connector, I found that data was not sent until the connection was closed
(never, in the case of my servlet.)
Traced the problem down to WarpResponse.java: for some reason it was
inheriting its stream from OutputStream instead of ServletOutputStream,
which was causing all sorts of problems. Also made sure it flushed the
headers before trying to write body data.
Seems to be going fine now, but this is my first patch so treat with
caution!
--
Roger Nesbitt
---
/root/wa/jakarta-tomcat-connectors/webapp/java/org/apache/catalina/connector/warp/WarpResponse.java
Thu Jan 24 06:48:50 2002
+++ WarpResponse.java Wed Feb 6 15:54:28 2002
@@ -71,6 +71,7 @@
import java.util.Locale;
import java.util.TimeZone;
import javax.servlet.ServletResponse;
+import javax.servlet.ServletOutputStream;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@@ -101,6 +102,21 @@
this.setStream(localstream);
}
+/**
+ * Returns the warp OutputStream
+ */
+public ServletOutputStream getOutputStream() { return localstream; }
+
+/**
+ * Flush the buffer and commit this response.
+ *
+ * @exception IOException if an input/output error occurs
+ */
+public void flushBuffer() throws IOException { localstream.flush(); }
+
+public int getBufferSize() { return localstream.packet.buffer.length; }
+public void setBufferSize(int size) {}
+
/**
* Recycle this codeWarpResponse/code instance.
*/
@@ -248,7 +264,7 @@
* The codeOutputStream/code that will handle all response body
* transmission.
*/
-protected class Stream extends OutputStream {
+protected class Stream extends ServletOutputStream {
/** The response associated with this stream instance. */
private WarpResponse response=null;
/** The packet used by this stream instance. */
@@ -285,6 +301,7 @@
public void flush()
throws IOException {
if (closed) throw new IOException(Stream closed);
+if (!response.isCommitted()) response.sendHeaders();
packet.setType(Constants.TYPE_RES_BODY);
response.getConnection().send(packet);
packet.reset();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 6208] - Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface
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=6208. 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=6208 Bug in Tomcat's implementation of the sendRedirect method of the HttpServletResponse interface [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2002-02-06 04:22 --- Remy writes: Send redirect doesn't really do that (look at the javadocs). I disagree. To quote from the javadocs (taken from the latest Servlet 2.3 spec): public void sendRedirect(java.lang.String location) throws java.io.IOException Sends a temporary redirect response to the client using the specified redirect location URL. This method can accept relative URLs... [discussion of relative URL handling ommitted] The first sentence above (Sends a temporary redirect response...) says that it ought to do what I originally stated in my bug report. The next sentence states that the redirect Url CAN be, but does not HAVE to be, relative. Therefore, I conclude that as far as the javadocs go, I should be able to call res.sendRedirect(jar:http://somehost/controllerMoz.jar!/controllerMoz.html;); as stated in my original bug report. Now, in my original code, before I had to worry about digital signatures, I used relative Urls, doing stuff like res.sendRedirect(/controllerMoz.html); which always worked. I just did an additional test with an http: absolute Url, res.sendRedirect(http://somehost/controllerMoz.html;); and the above also works fine; here is what the log file reports back for the response's header value: header=Location=http://166.84.156.61/controllerMoz.html which is exactly what I would expect. So tell me why http: protocol abosolute Urls should work just fine, but jar: protocol Urls get mutilated to just header=Location=jar: (when the response's header should be header=Location=jar:http://somehost/controllerMoz.jar!/controllerMoz.html ) Clearly, tomcat is somehow treating jar: absolute Urls differently than http: absolute Urls. Therefore, I maintain that this behavior is a bug, and I am reopening it. Instead, set the header and the status code yourself, and it should work. OK -- that should constitute a reasonable workaround of the bug. Thanks for the suggestion (it is better than an uglier workaround that I thought of). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
