RE: redirect from Servlet
Hi, thanks, I added the line. No 404 is present, but the servlet maintains, ie the browser is completely blank. What about the (/xxx.jsp) path? Thanks Paul. Try this getServletConfig().getServletContext().getRequestDispatcher(/xxx.jsp). forward(request, response); - Original Message - From: Paul Wallace [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:21 AM Subject: redirect from Servlet Hello, I have a packaged servlet (com.mypackage.servlets;) in WEB-INF\classes\com\mypackage\servlets, where it performs its logic dutifully. From the servlet I wish to redirect back to the JSP that called it. Currently the JSP origin cannot be found (404). I have tried all manner of variations of path: res.sendRedirect(addAgent.jsp); including a fully formed URL (local and HTTP). How do I redirect to the desired file please? Thanks Paul. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirect from Servlet
if your jsp is under $TOMCAT_HOME/webapps/admin/test/Test.jsp getServletConfig().getServletContext().getRequestDispatcher(/admin/test/Tes t.jsp).forward(request, response); thanx - Original Message - From: Paul Wallace [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:37 AM Subject: RE: redirect from Servlet Hi, thanks, I added the line. No 404 is present, but the servlet maintains, ie the browser is completely blank. What about the (/xxx.jsp) path? Thanks Paul. Try this getServletConfig().getServletContext().getRequestDispatcher(/xxx.jsp). forward(request, response); - Original Message - From: Paul Wallace [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:21 AM Subject: redirect from Servlet Hello, I have a packaged servlet (com.mypackage.servlets;) in WEB-INF\classes\com\mypackage\servlets, where it performs its logic dutifully. From the servlet I wish to redirect back to the JSP that called it. Currently the JSP origin cannot be found (404). I have tried all manner of variations of path: res.sendRedirect(addAgent.jsp); including a fully formed URL (local and HTTP). How do I redirect to the desired file please? Thanks Paul. - 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] - 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: mod_jk multiple slashes reveals jsp code
Palle Girgensohn wrote: --On onsdag, juni 25, 2003 11.16.02 +0200 Henri Gomez [EMAIL PROTECTED] wrote: Palle Girgensohn wrote: Hi, When using mod_jk and apache13: JkMount /app/*jsp ajp13 will redirect requests like http://server/app/foobar.jsp to tomcat, just fine. But, http://server//app/foobar.jsp will not be catched by JkMount, and apache will send the jsp source code to the browser. Of course, a rewrite can hinder this, but is it really meant to be this way? Is it just me having problems? Didn't have such behaviour with mod_jk 1.2.4 and tomcat 3.3.1a, got a 404 instead. BTW, I'm using JkMount /app/* ajp13 That's a different rule, match rule instead of suffix rule. The same code is responsible, though. If you get a 404, it is apache that cannot find the file you try to access for some other reason. The request never gets to tomcat. I too get 404 with that rule when accessing servlets this way, but I get jsp source code. Problem is that mod_jk only does a strncmp and never bothers to check for anomalities in the URL. The mod_jk design never cares about this problem, which is strange. It is coded this way on purpose. It not a bug, it is a design flaw. :( Could we stop useless critics and flams and be more positives. It's open source, and if you have objections, you're welcome to provide fixes. Never forget that mod_jk WAS DESIGNED to be cross web server compatible and that's why some of the Apache functions are not used. BTW, on the Tomcat side, there is some URI checks since this problem could also appears when using the built-in http connector. In the actual case the problem seems to be that Apache handle the jsp directly since it didn't forward it to tomcat (probably because apache and tomcat run on the same machine) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk multiple slashes reveals jsp code
On Thu, 26 Jun 2003, Henri Gomez wrote: Could we stop useless critics and flams and be more positives. I'm sorry that you think it is useless to point out the specific areas where mod_jk and mod_jk2 are doing things wrong. It's open source, and if you have objections, you're welcome to provide fixes. To be honest, that isn't too appealing given the sad state of all the different connectors available and the extremely poor state of documentation about what is what and how things are supposed to work. But that is irrelevant, and doesn't change the validity of pointing out what things are problems and why. What is the release plan for mod_jk2? Is there any plan for making it production quality? There doesn't seem to be much happening with it. Is one better served to work on mod_jk instead and give up on mod_jk2? Never forget that mod_jk WAS DESIGNED to be cross web server compatible and that's why some of the Apache functions are not used. mod_jk is the Apache specific module. The fact that there are other modules using some shared code that are specific to other webservers doesn't change anything. Web server specific plugins are the things that should tie tomcat in with the way the particular webserver works. It is quite sad to see how much worse webserver plugins have gotten since the days of mod_jserv. BTW, on the Tomcat side, there is some URI checks since this problem could also appears when using the built-in http connector. In the actual case the problem seems to be that Apache handle the jsp directly since it didn't forward it to tomcat (probably because apache and tomcat run on the same machine) The problem isn't that Apache doesn't forward it, the problem is that mod_jk doesn't forward it because it reimplements things that Apache can do for it a lot better and in a way that ensures it is compatible with everything else happening in the webserver. The same applies to other webservers. The mapping of what things should be passed to tomcat and what things shouldn't is a security critical area that can not be glossed over with a ahh, we'll just make up our own way of doing things since it means we don't have to bother with the webserver. It is a plugin for the webserver, you have to bother with how the webserver works. It was a bad design decision to take the shortcut of trying to embed all the configuration within shared code and reuse it for every webserver. By describing the problems, I'm hoping that someone who does have the time right now can actually make one of the multitude of Apache -- tomcat connectors into something production quality without gaping security, performance, and stability issues. If not, then it will have to wait until I am at a point in my day job where we need to be deploying our applications and they need to actually work right and I'll worry about it then. Oh, for whoever is trying to actually make mod_jk work right... you may be able to do a SetHandler jakarta-servlet inside a Files section in a Directory section, not sure if it supports it properly or not, although that doesn't let you specify a specific worker. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk multiple slashes reveals jsp code
Marc Slemko wrote: On Thu, 26 Jun 2003, Henri Gomez wrote: Could we stop useless critics and flams and be more positives. I'm sorry that you think it is useless to point out the specific areas where mod_jk and mod_jk2 are doing things wrong. If jk's does some things wrong, we're open to make them evolve, that's a devel list after all. It's open source, and if you have objections, you're welcome to provide fixes. To be honest, that isn't too appealing given the sad state of all the different connectors available and the extremely poor state of documentation about what is what and how things are supposed to work. But that is irrelevant, and doesn't change the validity of pointing out what things are problems and why. Sad state, are you sure ? There is plenty of sites which use it everyday for their productions purposes. No documentation, you're kidding, did you take a look at online documentation at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/doc/ http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/ What is the release plan for mod_jk2? Is there any plan for making it production quality? There doesn't seem to be much happening with it. Is one better served to work on mod_jk instead and give up on mod_jk2? We need more contributors, so once again you're welcome. Mladen and Costin make a great works in jk2 and there is now need for more serious tests and fix before it came production ready. Never forget that mod_jk WAS DESIGNED to be cross web server compatible and that's why some of the Apache functions are not used. mod_jk is the Apache specific module. The fact that there are other modules using some shared code that are specific to other webservers doesn't change anything. Of course but the 'common' modules make handle things which could be some time delegated to specific webservers, that's one of the big diff between jk and jk2. Web server specific plugins are the things that should tie tomcat in with the way the particular webserver works. All connectors works is done now on jakarta-tomcat-connectors and jk, jk2, coyote, http11 live there and are use by TC3/4/5. It is quite sad to see how much worse webserver plugins have gotten since the days of mod_jserv. Well there is 3 solutions for you : - You contribute code to make mod_jk/mod_jk2 better. - You get mod_jserv sources and make a successor, ie mod_jserv2, which will deprecate mod_jk easily if it perform better. - You develop a whole new connector module for Apache 1.3/Apache 2.0/IIS/Domino/iPlanet. Thanks to stop this flam thread if you only have critics to formulate and no suggestions or fixes. This is tomcat-dev list, pas le 'bureau des pleurs'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 234] - Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371
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=234. 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=234 Can't set multiple cookies in servlet response headers through Ajp13 BugRat Report#371 [EMAIL PROTECTED] changed: What|Removed |Added Status|UNCONFIRMED |NEW everconfirmed|0 |1 --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 09:56 --- I am using tomcat 4.1.24, jk2 and apache 2.0.43, and I have the same problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21105] New: - Tomcat RPM: /etc/profile.d
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=21105. 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=21105 Tomcat RPM: /etc/profile.d Summary: Tomcat RPM: /etc/profile.d Product: Tomcat 5 Version: 5.0.0 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Installable Packages AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Neil Zanella [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello, I would like to make the following suggestion for the Tomcat 4 RPM file: To conform with Red Hat's policy, and at the same time simplify the installation process, the following two files should be placed in the Red Hat compliant /etc/profile.d directory (these are used to set environment variables upon startup from various RPM packages): $ cat /etc/profile.d/tomcat.csh # Tomcat initialization script (csh) if ( $?CATALINA_HOME ) then exit endif setenv CATALINA_HOME /var/tomcat4 ... and ... $ cat /etc/profile.d/tomcat.sh # Tomcat initialization script (sh) if [ -z $CATALINA_HOME ] ; then CATALINA_HOME=/var/tomcat4 fi export CATALINA_HOME This sets CATALINA_HOME correctly according to the current installation of tomcat4 under /var/tomcat4 (whose correctness according to FHS I am not yet convinced of). Thanks! Neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] make sure mod_jk for Apache 2 is linked like apxs wouldhave done it
vtxclere is a Linux box. Linux with Apache 2.0.40? RH 9 by any chance? Henri had the problem with RH and Apache 2.0.40. I am just trying to help to fix it. Any news for the configure fixe, to have a 1.2.5 release soon ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
decrease idle threads in the pool faster...
Hi all... I have just installed Tomcat 4.1 on a Solaris box and I have realized a surprising effect: Thread pool creates new threads quickly when a request burst arrives, but the freeing when they become idle is very slow (besides, the computer is almost full cpu loaded). Due to this, several bursts carry out reaching the max number of processes, and Tomcat stops working. My intention is to force idle recent-used threads (lwp in Solaris) to be killed in a shorter period of time in order to mantain almost constant the number of lwps in the pool. So, I was going to dive into CoyoteConnector code to discover and decrease any freeing timeout of the idle threads, but perhaps some of you can guide me better to get what I need. Thanks in advance and best regards, Carlos RodrÃguez - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tomcat authentication
when using tomcat authentication realms; if the login page is login.jsp and if a user directly access this page and tries to login , tomcat returns the error given below. i need to catch this and handle it. specifically, where is the forwarding page reference stored? in the users session? what attribute is it? please help thanx riyaz == HTTP Status 400 - Invalid direct reference to form login page type Status report message Invalid direct reference to form login page description The request sent by the client was syntactically incorrect (Invalid direct reference to form login page). Apache Tomcat/4.1.24-LE-jdk14 == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build Failure - jakarta-tomcat-5
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2003-06-26/jakarta-tomcat-5.html Buildfile: build.xml prepare-release: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0 [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/bin [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/release/v5.0/src init: [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/classes [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib deploy-static: [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/common/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib [copy] Copying 1 file to /home/rubys/jakarta/jakarta-tomcat-5/build/server/lib BUILD FAILED /home/rubys/jakarta/jakarta-tomcat-5/build.xml:156: Warning: Could not find file /usr/local/commons-daemon/bin/jsvc.tar.gz to copy. Total time: 4 seconds - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: redirect from Servlet
Howdy, Not quite. RequestDispatcher is relative to the context root, so /test/Test.jsp. But he wanted to use sendRedirect anyways, so you would do response.sendRedirect(request.getContextPath() + Test.jsp); Assuming Test.jsp is under the context root. Yoav Shapira --- Dayan Simon [EMAIL PROTECTED] wrote: if your jsp is under $TOMCAT_HOME/webapps/admin/test/Test.jsp getServletConfig().getServletContext().getRequestDispatcher(/admin/test/Tes t.jsp).forward(request, response); thanx - Original Message - From: Paul Wallace [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:37 AM Subject: RE: redirect from Servlet Hi, thanks, I added the line. No 404 is present, but the servlet maintains, ie the browser is completely blank. What about the (/xxx.jsp) path? Thanks Paul. Try this getServletConfig().getServletContext().getRequestDispatcher(/xxx.jsp). forward(request, response); - Original Message - From: Paul Wallace [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Thursday, June 26, 2003 11:21 AM Subject: redirect from Servlet Hello, I have a packaged servlet (com.mypackage.servlets;) in WEB-INF\classes\com\mypackage\servlets, where it performs its logic dutifully. From the servlet I wish to redirect back to the JSP that called it. Currently the JSP origin cannot be found (404). I have tried all manner of variations of path: res.sendRedirect(addAgent.jsp); including a fully formed URL (local and HTTP). How do I redirect to the desired file please? Thanks Paul. - 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] - 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] = Yoav Shapira [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
multiuser setup: please help
Hello, I have successfully setup Tomcat but now I want the following: Suppose some Linux based system has a dynamic and constantly changing number of users ranging in the thousands. I would like to set up tomcat so that: Each user gets a context root in a directory such as: http://localhost:8080/~johndoe/contextroot/ This happens in such a way that when a request to a subdirectory that looks like the one above is issued, Tomcat automatically knows how to handle it. Is this possible? This would be ideal. I don't see why it shouldn't be possible. If this is impossible, then consider it to be a missing feature from tomcat. I almost feel it should be documented somewhere if available, otherwise, if not available, it should be implemented. I guess I could define a path mapping of the form: http://localhost:8080/~+/contextroot/ I actually tried this but it did not work: I used the path mapping inside the webapps/ROOT/WEB-INF/web.xml file: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-namewelcome/display-name descriptionThese examples are from the created contextroot subdirectory of webapps./description servlet servlet-namewelcome/servlet-name descriptionThis web application welcomes you./description servlet-classWelcomeServlet/servlet-class /servlet servlet-mapping servlet-namewelcome/servlet-name url-patternhttp://localhost:8080/~*/contextroot/*/url-pattern /servlet-mapping /web-app I thought I could have the URL execute a servlet, that would execute then execute a servlet from the users' directory. Sound complicated? Perhaps there is an easier way??? Suggestions very welcome!!! Neil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Working on patch (need feedback)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16541 How close is the working JNDIRealm solution to being added? I have never got an answer or comment to my added JNDIRealm* classes from an tomcat-developer, so it looks like there isnt currently a developer assigned to the JNDI authentication stuff. And i think we have no chances to get anything of this into 4.1.25. So maybe the currently only available solution for us, is to copy the JNDIRealm source out of the tomcat sourcetree and use a self patched version. This is what i currently do for my client-cert authentication stuff. Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19627] - Implementing ContainerServlet doesn't work outside the org.apache.cataliana package.
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=19627. 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=19627 Implementing ContainerServlet doesn't work outside the org.apache.cataliana package. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:40 --- Placing servlet in $CATALINA_HOME/server/lib and marking the context as privileged works. I'll attach the simple test servlet I used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 19627] - Implementing ContainerServlet doesn't work outside the org.apache.cataliana package.
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=19627. 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=19627 Implementing ContainerServlet doesn't work outside the org.apache.cataliana package. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:40 --- Placing servlet in $CATALINA_HOME/server/lib and marking the context as privileged works. I'll attach the simple test servlet I used. - 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]
DO NOT REPLY [Bug 20086] - Broken link for JK Documentation
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=20086. 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=20086 Broken link for JK Documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:40 --- Created an attachment (id=7000) Test container servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Working on patch (need feedback)
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16541 How close is the working JNDIRealm solution to being added? I have never got an answer or comment to my added JNDIRealm* classes from an tomcat-developer, so it looks like there isnt currently a developer assigned to the JNDI authentication stuff. And i think we have no chances to get anything of this into 4.1.25. So maybe the currently only available solution for us, is to copy the JNDIRealm source out of the tomcat sourcetree and use a self patched version. This is what i currently do for my client-cert authentication stuff. Mario - 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: DO NOT REPLY [Bug 20086] - Broken link for JK Documentation
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=20086. 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=20086 Broken link for JK Documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:40 --- Created an attachment (id=7000) Test container servlet - 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]
DO NOT REPLY [Bug 19627] - Implementing ContainerServlet doesn't work outside the org.apache.cataliana package.
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=19627. 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=19627 Implementing ContainerServlet doesn't work outside the org.apache.cataliana package. --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:42 --- Created an attachment (id=7001) Test container servlet - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20086] - Broken link for JK Documentation
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=20086. 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=20086 Broken link for JK Documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:42 --- Attached test container servlet for the wrong bug, please ignore ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:57 --- I haven't found an existing solution to this problem, so I played a bit with the source and I have working fix for that. First of all I am not very familiar with the procedure of applying patches to CVS (I mean I don't know if shall I report it before commiting anything or ask for a permission or anything else), so I didn't put it into the repository. Instead I will give out the source and/or binaries if somebody asks. I'll be happy if the patches would hit the repository anyway. Okay, here's the trick: now SSIServlet handles two more init-parameters, ie. defaultInputEncoding and defaultOutputEncoding. First one tells the SSIInclude command to treat all processed (and included) files as they were written in this charset (by creating appriopriate readers). The second sets Content- Type's charset attribute to given value and thus allow to create proper writer. This forced me to add two methods to SSIExternalResolver interface: getDefaultInputEncoding and getDefaultOutputEncoding. Both return objects of the type java.nio.charset.Charset, that hold appropriate charsets. If happens, that certain included file is in different charset than the rest, then it's charset can be entered after the file name. I was thinking of using separate parameter, but it would break NCSA standard, besides !--#include command allows any number of file/virtual parameters, so it would have to be written like this: !--#include file=foo.txt charset=iso-8859-2 file=bar.txt charset=iso-8859-1-- and so on. Well, maybe it's not bad, but as I've written, it breaks NCSA standard. So instead I've used the same syntax as in mail headers. So now we shall write: !--#include file=foo.txt;charset=iso-8859-2 file=bar.txt; charset = iso-8859-1-- a.s.o. I hope this will not break any rule, and I know---it's questionable. This, however, solves my problems with incorrect output, and if we have all the files in the same charset, we do not have to use ...;charset=X construction (to be honest, I haven't tested the charset stuff just mentioned). Default encodings works however flawlessly. If anyone is interrested in this patch, please contact me. If Tomcat developers find this patch usefull or not too dirty/nasty, then I gladly add my .02 to the contribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 10385] - SSI-Servlet produces invalid character encoding information
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10385 SSI-Servlet produces invalid character encoding information [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:57 --- I haven't found an existing solution to this problem, so I played a bit with the source and I have working fix for that. First of all I am not very familiar with the procedure of applying patches to CVS (I mean I don't know if shall I report it before commiting anything or ask for a permission or anything else), so I didn't put it into the repository. Instead I will give out the source and/or binaries if somebody asks. I'll be happy if the patches would hit the repository anyway. Okay, here's the trick: now SSIServlet handles two more init-parameters, ie. defaultInputEncoding and defaultOutputEncoding. First one tells the SSIInclude command to treat all processed (and included) files as they were written in this charset (by creating appriopriate readers). The second sets Content- Type's charset attribute to given value and thus allow to create proper writer. This forced me to add two methods to SSIExternalResolver interface: getDefaultInputEncoding and getDefaultOutputEncoding. Both return objects of the type java.nio.charset.Charset, that hold appropriate charsets. If happens, that certain included file is in different charset than the rest, then it's charset can be entered after the file name. I was thinking of using separate parameter, but it would break NCSA standard, besides !--#include command allows any number of file/virtual parameters, so it would have to be written like this: !--#include file=foo.txt charset=iso-8859-2 file=bar.txt charset=iso-8859-1-- and so on. Well, maybe it's not bad, but as I've written, it breaks NCSA standard. So instead I've used the same syntax as in mail headers. So now we shall write: !--#include file=foo.txt;charset=iso-8859-2 file=bar.txt; charset = iso-8859-1-- a.s.o. I hope this will not break any rule, and I know---it's questionable. This, however, solves my problems with incorrect output, and if we have all the files in the same charset, we do not have to use ...;charset=X construction (to be honest, I haven't tested the charset stuff just mentioned). Default encodings works however flawlessly. If anyone is interrested in this patch, please contact me. If Tomcat developers find this patch usefull or not too dirty/nasty, then I gladly add my .02 to the contribution. - 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
DO NOT REPLY [Bug 21115] New: - JDBCRealm does not work with HTTPS client certificate authentication
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=21115.
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=21115
JDBCRealm does not work with HTTPS client certificate authentication
Summary: JDBCRealm does not work with HTTPS client certificate
authentication
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Description:
In org.apache.catalina.realm.JDBCRealm, the method protected Principal
getPrincipal(String username), implementing an abstract method inherited from
org.apache.catalina.realm.RealmBase is not properly implemented : it simply
returns null. The consequence is that if any client with a valid HTTPS
certificate tries to connect to a webapp with CLIENT-CERT authorization login,
he will not be identified by the system and get a HTTP402 error (something
telling that his credentials are not sufficient...).
A Solution:
In order to make it work, I simply implemented that method as follows:
protected Principal getPrincipal(String username) {
Principal result = authenticate(username, tomcat);
return result;
}
In the DB, for each client you have to put the full DN of the client
certificate into the 'login' column, and 'tomcat' as password.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21116] New: - EOFException thrown - seemingly random
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=21116. 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=21116 EOFException thrown - seemingly random Summary: EOFException thrown - seemingly random Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Our client's Tomcat installation seems to throw this at random times. I'm not what the effect is. It's running the web server that comes with Tomcat. O/S is Windows 2000 Server version 5.0.2195 SP3 Build 2195 2003-06-20 12:41:33 server: Replied to the client 2003-06-20 12:41:33 StandardWrapperValve[server]: Servlet.service() for servlet server threw exception java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2165) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2634) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734) at java.io.ObjectInputStream.init(ObjectInputStream.java:253) at com.btec.server.BTecServlet.doPost(BTecServlet.java:25) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:632) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:590) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:707) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530) at java.lang.Thread.run(Thread.java:536) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19667] - Using commit on admin app does not save keystore password
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=19667. 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=19667 Using commit on admin app does not save keystore password --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 16:58 --- I've learned more about this bug. First of all, it only applies to the o.a.catalina.net.SSLServerSocketFactory. If you're using the Coyote classes, this bug doesn't appear. The reason is that someone removed the getter for keystorePass from the SSLServerSocketFactory. That's what's used by the Manager to recreate the server.xml file. Here's the relevant commit info: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java?rev=1.8content-type=text/vnd.viewcvs-markup This also led me to a fix. - Get the latest version of SSLServerSocketFactory. - Re-add the getter for getKeystorePass and compile. - Copy the resulting class file to $TOMCAT_HOME/server/classes/org/apache/catalina/net Restart. That should fix it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21115] New: - JDBCRealm does not work with HTTPS client certificate authentication
Hello,
You are receiving this message in follow-up to a report
received by the EarthLink Abuse Department. You may have
submitted this report to a number of addresses including but
not limited to [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
or [EMAIL PROTECTED]
Most reports of network abuse sent to this department fall
into a few recognizable categories (spam, cracking, viruses,
etc.). To increase efficiency, our filters scan incoming
reports and attempt to determine the general type of issue
being reported.
We were not able to process your report because it does not
appear to include the information needed for EarthLink Abuse
to begin it's investigation. Evidence to Abuse should always
include the IP address of the offending party and a valid
timestamp, which includes time, date and timezone.
To learn how to report spam so action is taken:
http://spam.abuse.net/userhelp/howtocomplain.shtml
To learn how to locate and interpret e-mail headers in your
e-mail client:
http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp
Other useful lookup tools:
http://samspade.org/
Once you have included the pertinent information needed,
please resubmit your report, and include this autoresponse.
Your report will then be reprocessed by our filters.
However, you should expect to receive another auto-response
after your resubmission is re-examined, but due to the large
number of reports we receive, please understand that you may
not receive a personal response.
Our policies can be found at the following page:
http://earthlink.net/about/policies/
Thanks,
The EarthLink Abuse Staff
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=21115.
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=21115
JDBCRealm does not work with HTTPS client certificate authentication
Summary: JDBCRealm does not work with HTTPS client certificate
authentication
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Major
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Description:
In org.apache.catalina.realm.JDBCRealm, the method protected Principal
getPrincipal(String username), implementing an abstract method inherited from
org.apache.catalina.realm.RealmBase is not properly implemented : it simply
returns null. The consequence is that if any client with a valid HTTPS
certificate tries to connect to a webapp with CLIENT-CERT authorization login,
he will not be identified by the system and get a HTTP402 error (something
telling that his credentials are not sufficient...).
A Solution:
In order to make it work, I simply implemented that method as follows:
protected Principal getPrincipal(String username) {
Principal result = authenticate(username, tomcat);
return result;
}
In the DB, for each client you have to put the full DN of the client
certificate into the 'login' column, and 'tomcat' as password.
-
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: DO NOT REPLY [Bug 21116] New: - EOFException thrown - seemingly random
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21116. 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=21116 EOFException thrown - seemingly random Summary: EOFException thrown - seemingly random Product: Tomcat 4 Version: 4.1.18 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Our client's Tomcat installation seems to throw this at random times. I'm not what the effect is. It's running the web server that comes with Tomcat. O/S is Windows 2000 Server version 5.0.2195 SP3 Build 2195 2003-06-20 12:41:33 server: Replied to the client 2003-06-20 12:41:33 StandardWrapperValve[server]: Servlet.service() for servlet server threw exception java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2165) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2634) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734) at java.io.ObjectInputStream.init(ObjectInputStream.java:253) at com.btec.server.BTecServlet.doPost(BTecServlet.java:25) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at
Re: DO NOT REPLY [Bug 20086] - Broken link for JK Documentation
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=20086. 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=20086 Broken link for JK Documentation --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:42 --- Attached test container servlet for the wrong bug, please ignore ;) - 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: DO NOT REPLY [Bug 19627] - Implementing ContainerServlet doesn't work outside the org.apache.cataliana package.
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=19627. 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=19627 Implementing ContainerServlet doesn't work outside the org.apache.cataliana package. --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 17:42 --- Created an attachment (id=7001) Test container servlet - 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: DO NOT REPLY [Bug 19667] - Using commit on admin app does not save keystore password
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=19667. 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=19667 Using commit on admin app does not save keystore password --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 16:58 --- I've learned more about this bug. First of all, it only applies to the o.a.catalina.net.SSLServerSocketFactory. If you're using the Coyote classes, this bug doesn't appear. The reason is that someone removed the getter for keystorePass from the SSLServerSocketFactory. That's what's used by the Manager to recreate the server.xml file. Here's the relevant commit info: http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java?rev=1.8content-type=text/vnd.viewcvs-markup This also led me to a fix. - Get the latest version of SSLServerSocketFactory. - Re-add the getter for getKeystorePass and compile. - Copy the resulting class file to $TOMCAT_HOME/server/classes/org/apache/catalina/net Restart. That should fix it. - 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: mod_jk multiple slashes reveals jsp code
Marc Slemko wrote: On Thu, 26 Jun 2003, Henri Gomez wrote: By describing the problems, I'm hoping that someone who does have the time right now can actually make one of the multitude of Apache -- tomcat connectors into something production quality without gaping security, performance, and stability issues. If not, then it will have to wait until I am at a point in my day job where we need to be deploying our applications and they need to actually work right and I'll worry about it then. Oh, for whoever is trying to actually make mod_jk work right... you may be able to do a SetHandler jakarta-servlet inside a Files section in a Directory section, not sure if it supports it properly or not, although that doesn't let you specify a specific worker. Nice whine ;-) If you someday choose to dedicate the same kind of effort on contributing to TC, I would be very happy (a a lot of people would be very grateful too) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: mod_jk multiple slashes reveals jsp code
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff Marc Slemko wrote: On Thu, 26 Jun 2003, Henri Gomez wrote: By describing the problems, I'm hoping that someone who does have the time right now can actually make one of the multitude of Apache -- tomcat connectors into something production quality without gaping security, performance, and stability issues. If not, then it will have to wait until I am at a point in my day job where we need to be deploying our applications and they need to actually work right and I'll worry about it then. Oh, for whoever is trying to actually make mod_jk work right... you may be able to do a SetHandler jakarta-servlet inside a Files section in a Directory section, not sure if it supports it properly or not, although that doesn't let you specify a specific worker. Nice whine ;-) If you someday choose to dedicate the same kind of effort on contributing to TC, I would be very happy (a a lot of people would be very grateful too) :) Remy - 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]
DO NOT REPLY [Bug 19824] - symbolic links not followed when looking for servlets
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=19824. 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=19824 symbolic links not followed when looking for servlets [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED Version|4.1.12 |4.1.24 --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:45 --- The reason for this bug is the same as discussed in Bug 17401, and the solution is the same. Below you will find the quote. This solved your problem for me. (The thing did cost me several hours and nerves.) --- Additional Comments From Jess Holle 2003-03-22 06:56 --- This bug should be changed to a documentation bug and quickly fixed. Tomcat 4.1.18 (and 4.1.24) both support symbolic linking. One just has to add insert a Resources element in the server.xml enabling it, e.g.: Context Resources allowLinking=true/ /Context Unfortunately, this is not documented in the Tomcat docs. Only by reading source code and doing specific Tomcat mailing list and google searches based on my reading was I able to figure this out! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 19824] - symbolic links not followed when looking for servlets
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=19824. 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=19824 symbolic links not followed when looking for servlets [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED Version|4.1.12 |4.1.24 --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 15:45 --- The reason for this bug is the same as discussed in Bug 17401, and the solution is the same. Below you will find the quote. This solved your problem for me. (The thing did cost me several hours and nerves.) --- Additional Comments From Jess Holle 2003-03-22 06:56 --- This bug should be changed to a documentation bug and quickly fixed. Tomcat 4.1.18 (and 4.1.24) both support symbolic linking. One just has to add insert a Resources element in the server.xml enabling it, e.g.: Context Resources allowLinking=true/ /Context Unfortunately, this is not documented in the Tomcat docs. Only by reading source code and doing specific Tomcat mailing list and google searches based on my reading was I able to figure this out! - 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]
SIP Servlet revisited
Hey Guys, A little over a year ago the posibility for making an implementation of the SIP Servlet specification using Tomcat was shortly talked about (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg25333.html) I have done some tests and looked into what problems this would present and I came to one conclusion; The current design of the org.apache.catalina.Session interface requires that you do some weird hacking, twisting and adaptation to get support for sessions in SIP, since Session expects to always wrap a HttpSession, but SIP Servlets have their own session interface. I have talked to Anders Kristensen about these difference session interfaces. He said that even though there had been talks with the Servlet expert group about making a general servlet session interface fitting the need of both HTTP and SIP it was voted against in the Servlet expert group. The reason they gave for not making such an interface was the small spread and use of SIP servlets. Until such an interface is designed I was wondering if it would be possible to change the org.apache.catalina.Session interface to return a temporary internal Tomcat interface that contains the same methods that would probably end up in the general Servlet session interface?? - Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SIP Servlet revisited
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff Hey Guys, A little over a year ago the posibility for making an implementation of the SIP Servlet specification using Tomcat was shortly talked about (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg25333.html) I have done some tests and looked into what problems this would present and I came to one conclusion; The current design of the org.apache.catalina.Session interface requires that you do some weird hacking, twisting and adaptation to get support for sessions in SIP, since Session expects to always wrap a HttpSession, but SIP Servlets have their own session interface. I have talked to Anders Kristensen about these difference session interfaces. He said that even though there had been talks with the Servlet expert group about making a general servlet session interface fitting the need of both HTTP and SIP it was voted against in the Servlet expert group. The reason they gave for not making such an interface was the small spread and use of SIP servlets. Until such an interface is designed I was wondering if it would be possible to change the org.apache.catalina.Session interface to return a temporary internal Tomcat interface that contains the same methods that would probably end up in the general Servlet session interface?? - Brian - 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]
DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
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=20376. 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=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 18:40 --- Any one is having this problem, I have noticed it on more than one machine so far. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=20376. 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=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 18:40 --- Any one is having this problem, I have noticed it on more than one machine so far. - 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]
DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
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=20376. 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=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Critical - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 20376] - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=20376. 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=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Critical - 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: SIP Servlet revisited
Can one of admins take a look at the Earthlink subscribtion and unsubscribe them. Sam -Original Message- From: Earthlink Abuse Department [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: Re: SIP Servlet revisited Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_heade rs.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff Hey Guys, A little over a year ago the posibility for making an implementation of the SIP Servlet specification using Tomcat was shortly talked about (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg25333.html ) I have done some tests and looked into what problems this would present and I came to one conclusion; The current design of the org.apache.catalina.Session interface requires that you do some weird hacking, twisting and adaptation to get support for sessions in SIP, since Session expects to always wrap a HttpSession, but SIP Servlets have their own session interface. I have talked to Anders Kristensen about these difference session interfaces. He said that even though there had been talks with the Servlet expert group about making a general servlet session interface fitting the need of both HTTP and SIP it was voted against in the Servlet expert group. The reason they gave for not making such an interface was the small spread and use of SIP servlets. Until such an interface is designed I was wondering if it would be possible to change the org.apache.catalina.Session interface to return a temporary internal Tomcat interface that contains the same methods that would probably end up in the general Servlet session interface?? - Brian - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SIP Servlet revisited
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Our ticketing system would seem to indicate that this is a report about junk email. Unfortunately, the email message you forwarded does not contain the extended header information we need to determine its true origin. All current email software applications have an option to view or show extended headers information. If you are unsure of how to display and send complete headers, the following web page(s) may offer some assistance: http://spam.abuse.net/userhelp/howtocomplain.shtml http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp More than likely, we have received complaints from other internet users about this same issue with all the headers that are necessary to investigate and take action, so resubmission of a particular junk email complaint is generally not necessary. The Earthlink Appropriate Use Policy, Users Agreement, and Privacy Policy can be found at: http://earthlink.net/about/policies/ If you believe we have misidentified your issue or that it needs further attention, please forward this message in its entirety to [EMAIL PROTECTED] for personal review. Due to the variety of reporting formats we receive, it is possible that our automated preprocessing has misidentified your report. We strongly encourage the use of SpamCop http://spamcop.net/, a spam reporting service which uses a standardized format that allows us to quickly identify your report, and will also help insure that your complaint reaches the appropriate party. If this mail is resubmitted without the complete header information, but concerning an incident that we have already resolved, you may not receive a personal response. Please do not interpret our efforts to pre-process incoming email as our being any less dedicated to preventing violations of our AUP. As we have grown, we have actively sought ways to more quickly and efficiently serve our customers and the internet community at large. It is our hope that by enacting this type of automated pre-processing that we will, in the end, be more responsive to matters as they are brought to our attention. -- EarthLink Abuse Staff Can one of admins take a look at the Earthlink subscribtion and unsubscribe them. Sam -Original Message- From: Earthlink Abuse Department [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: Re: SIP Servlet revisited Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_heade rs.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff Hey Guys, A little over a year ago the posibility for making an implementation of the SIP Servlet specification using Tomcat was shortly talked about (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg25333.html ) I have done some tests and looked into what problems this would present and I came to one conclusion; The current design of the org.apache.catalina.Session interface requires that you do some weird hacking, twisting and adaptation to get support for sessions in SIP, since Session expects to always wrap a HttpSession, but SIP Servlets have their own session interface. I have talked to Anders Kristensen about these difference
DO NOT REPLY [Bug 21124] New: - IE cookie handling breaks interaction between single user and multiple appservers
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=21124. 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=21124 IE cookie handling breaks interaction between single user and multiple appservers Summary: IE cookie handling breaks interaction between single user and multiple appservers Product: Tomcat 4 Version: 4.0.6 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] IN GENERAL: For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and if two different J2EE app servers are hosting those domains, the following will be true, assuming that the two appservers create session cookies that are identical except for the domain (note that a cookie consists of: name, domain, path, expiration): * If a user, running Internet Explorer, uses J2EE apps running on both domains, causing a session to be established on both domains simultaneously, the client accessing the application running in domain B will not be able to access a session established in domain B. This is due to the fact that IE orders cookies from least-specific to most- specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server that looks for the FIRST cookie named JSESSIONID will be susceptible to this problem. EXAMPLE: In our case, tomcat was serving up JSPs on x.com, causing a J2EE servlet session to be created when that page was loaded. Immediately after hitting x.com, w.x.com was being loaded, which also caused a session to be created. Both sessions were being identified by cookies set in the client browser. The cookies both had an ID of JSESSIONID, with an identical path. The only difference between the cookies was the domain (one was x.com, and the other was w.x.com). When interacting with the app on w.x.com, each request included an HTTP header specifying client-side cookies. In that header, the JSESSIONID created by x.com was ordered BEFORE the JSESSIONID created by w.x.com. The appserver on domain w.x.com was consequently attempting to find the session that had been created on x.com, and since it could not, was creating a new session with each request. Unfortunately, IE does NOT disobey the Cookie spec. The spec is ambiguous about what to do in this scenario, and Microsoft (big surprise) just chose to do things differently than everyone else. The spec (RFC 2109) says in section 4.3.4: If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. *** Ordering with respect to other attributes (e.g., Domain) is unspecified.*** I added the emphasis. I don't see a good solution to the problem, other than removing the mandate in the servlet spec that says JSESSIONID must be used to identify the cookie... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21124] New: - IE cookie handling breaks interaction between single user and multiple appservers
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21124. 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=21124 IE cookie handling breaks interaction between single user and multiple appservers Summary: IE cookie handling breaks interaction between single user and multiple appservers Product: Tomcat 4 Version: 4.0.6 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] IN GENERAL: For any two domains, A and B, if B is a subdomain of A (e.g., B.A), and if two different J2EE app servers are hosting those domains, the following will be true, assuming that the two appservers create session cookies that are identical except for the domain (note that a cookie consists of: name, domain, path, expiration): * If a user, running Internet Explorer, uses J2EE apps running on both domains, causing a session to be established on both domains simultaneously, the client accessing the application running in domain B will not be able to access a session established in domain B. This is due to the fact that IE orders cookies from least-specific to most- specific WITH RESPECT TO DOMAIN in an HTTP request. ANY app server that looks for the FIRST cookie named JSESSIONID will be susceptible to this problem. EXAMPLE: In our case, tomcat was serving up JSPs on x.com, causing a J2EE servlet session to be created when that page was loaded. Immediately after hitting x.com, w.x.com was being loaded, which also caused a session to be created. Both sessions were being identified by cookies set in the client browser. The cookies both had an ID of JSESSIONID, with an identical path. The only difference between the cookies was the domain (one was x.com, and the other was w.x.com). When interacting with the app on w.x.com, each request included an HTTP header specifying client-side cookies. In that header, the JSESSIONID created by x.com was ordered BEFORE the JSESSIONID created by w.x.com. The appserver on domain w.x.com was consequently attempting to find the session that had been created on x.com, and since it could not, was creating a new session with each request. Unfortunately, IE does NOT disobey the Cookie spec. The spec is ambiguous about what to do in this scenario, and Microsoft (big surprise) just chose to do things differently than everyone else. The spec (RFC 2109) says in section 4.3.4: If multiple cookies satisfy the criteria above, they are ordered in the Cookie header such that those with more specific Path attributes precede those with less specific. *** Ordering with respect to other attributes (e.g., Domain) is unspecified.*** I added the emphasis. I don't see a good solution to the problem, other than removing the mandate in the servlet spec that says JSESSIONID must be used to identify the cookie... - To unsubscribe, e-mail: [EMAIL
DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:11 --- *** This bug has been marked as a duplicate of 7813 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:11 --- *** This bug has been marked as a duplicate of 7813 *** - 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]
DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- Reopening to put the right bug# in - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- Reopening to put the right bug# in - 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]
DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- *** This bug has been marked as a duplicate of 7831 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
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=7831. 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=7831 [PATCH] JNDIRealm does not work with CLIENT-CERT auth method [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||m.com --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- *** Bug 21115 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21115] - JDBCRealm does not work with HTTPS client certificate authentication
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21115. 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=21115 JDBCRealm does not work with HTTPS client certificate authentication [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- *** This bug has been marked as a duplicate of 7831 *** - 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: DO NOT REPLY [Bug 7831] - [PATCH] JNDIRealm does not work with CLIENT-CERT auth method
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=7831. 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=7831 [PATCH] JNDIRealm does not work with CLIENT-CERT auth method [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] ||m.com --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:12 --- *** Bug 21115 has been marked as a duplicate of this bug. *** - 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]
DO NOT REPLY [Bug 21126] New: - mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected
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=21126. 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=21126 mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected Summary: mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected Product: Tomcat 4 Version: 4.1.25 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a configuration with 2 Sun / Solaris 8 servers running apache web server 2.0.45 and 2 Sun Solaris 8 Servers running Tomcat 4.1.25. The 2 apache web servers are connected to the 2 tomcat servers using mod_jk. A user logs in to tomcat 1 via apache server 1. In order to test failover, we then unplugged the network cable for tomcat 1, expecting that apache server 1 would not redirect to requests to tomcat server 2. It didn't, instead it kept attempting to send requests to tomcat 1. We also tested mod_jk2 in the same scenario and it too failed to failover correctly. Failover works correctly when either tomcat is shut down properly with ./shutdown.sh We tested the same scenario on a Ms Windows 2000 platform and it also worked correctly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21126] New: - mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21126. 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=21126 mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected Summary: mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected Product: Tomcat 4 Version: 4.1.25 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a configuration with 2 Sun / Solaris 8 servers running apache web server 2.0.45 and 2 Sun Solaris 8 Servers running Tomcat 4.1.25. The 2 apache web servers are connected to the 2 tomcat servers using mod_jk. A user logs in to tomcat 1 via apache server 1. In order to test failover, we then unplugged the network cable for tomcat 1, expecting that apache server 1 would not redirect to requests to tomcat server 2. It didn't, instead it kept attempting to send requests to tomcat 1. We also tested mod_jk2 in the same scenario and it too failed to failover correctly. Failover works correctly when either tomcat is shut down properly with ./shutdown.sh We tested the same scenario on a Ms Windows 2000 platform and it also worked correctly. - 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]
URL typo in build.properties.
Hi, I just now downloaded the tomcat-5 src and when i try to build, i got a build error for the wrong url- http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz This should be changed to - http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0-rc1.tar.gz in build.properties. Thanks, -Uday.
DO NOT REPLY [Bug 21126] - mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected
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=21126. 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=21126 mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:27 --- Sorry, the line ... expecting that apache server 1 would not redirect to requests to tomcat server 2. should of course read ... expecting that apache server 1 would now redirect requests to tomcat server 2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL typo in build.properties.
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff --Boundary_(ID_e63s3uGkuffVoJ9gCyJFrQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Hi, I just now downloaded the tomcat-5 src and when i try to build, i got a build error for the wrong url- http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz This should be changed to - http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0-rc1.tar.gz in build.properties. Thanks, -Uday. --Boundary_(ID_e63s3uGkuffVoJ9gCyJFrQ)-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21126] - mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21126. 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=21126 mod_jk / mod_jk2 doesn't fail over correctly when tomcat node disconnected --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 19:27 --- Sorry, the line ... expecting that apache server 1 would not redirect to requests to tomcat server 2. should of course read ... expecting that apache server 1 would now redirect requests to tomcat server 2. - 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]
DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context
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=16316. 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=16316 DataSourceRealm can not find JNDI name in context --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 20:34 --- I too believe this should be re-opened and fixed. Our manifestation of the defect is a little different. Again, our webapps/appname.xml file defines both the JDBCRealm and our application datasource. Both authentication and application database access work initially - UNTIL things go inactive and the MySQL 8hr timeout occurs. The fix for this is supposed to be to add ?autoReconnect=true to the end of the JDBC URL - so we added this. However this does not fix the problem, the timeouts during authentication still occur. Moving the entire context (with both datasource and JDBCRealm within) to server.xml appears to fix the timeouts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 16316] - DataSourceRealm can not find JNDI name in context
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=16316. 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=16316 DataSourceRealm can not find JNDI name in context --- Additional Comments From [EMAIL PROTECTED] 2003-06-26 20:34 --- I too believe this should be re-opened and fixed. Our manifestation of the defect is a little different. Again, our webapps/appname.xml file defines both the JDBCRealm and our application datasource. Both authentication and application database access work initially - UNTIL things go inactive and the MySQL 8hr timeout occurs. The fix for this is supposed to be to add ?autoReconnect=true to the end of the JDBC URL - so we added this. However this does not fix the problem, the timeouts during authentication still occur. Moving the entire context (with both datasource and JDBCRealm within) to server.xml appears to fix the timeouts. - 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]
DO NOT REPLY [Bug 21129] New: - Error message : The Parameter is incorrect when doing multipart requests (fileupload)
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=21129. 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=21129 Error message : The Parameter is incorrect when doing multipart requests (fileupload) Summary: Error message : The Parameter is incorrect when doing multipart requests (fileupload) Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] --- Description : I am using isapi_redirector2.dll and coyote connector with the usual setup. Sometimes (not everytime, maybe one in every 5 or more) I get the response error Parameter is incorrect when doing multipart requests (fileupload). In some occations, when this error has occured once, the request does not seem to be performed, the file in the upload does not reach tomcat, and the application that I use returns nulls. --- SETUP My setup is described in detail on the website http://www.reynir.net/tomcat/tomcat_IIS_service_jk2.html --- Reoccurance I've tested this with versions 2.0.2 and 2.0.1, and on at least 5 different computers in different networks with the same or very similar behaviour. The error does not occure with previous versions of the connector (isapi_redirect.dll). ERROR MESSAGES : Error log from the jklogfile : Error: [jk_worker_ajp13.c (512)]: ajp13.service() Error forwarding ajp13:ust_is:8009 1 0 Error: [jk_worker_ajp13.c (416)]: ajp13.service() ajpGetReply recoverable error 3 Error: [jk_handler_response.c (178)]: handler.response() Error sending response Error: [jk_service_iis.c (157)]: jk_ws_service_t::head, ServerSupportFunction failed Error: [jk_worker_ajp13.c (416)]: ajp13.service() ajpGetReply recoverable error 3 Error: [jk_handler_response.c (200)]: Error ajp_process_callback - write failed Error: [jk_service_iis.c (247)]: jk_ws_service_t::write, WriteClient failed For any additional information please contact me, reynir[AT]hugsmidjan.is - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 21129] New: - Error message : The Parameter is incorrect when doing multipart requests (fileupload)
Hello, You are receiving this message in follow-up to a report received by the EarthLink Abuse Department. You may have submitted this report to a number of addresses including but not limited to [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] Most reports of network abuse sent to this department fall into a few recognizable categories (spam, cracking, viruses, etc.). To increase efficiency, our filters scan incoming reports and attempt to determine the general type of issue being reported. We were not able to process your report because it does not appear to include the information needed for EarthLink Abuse to begin it's investigation. Evidence to Abuse should always include the IP address of the offending party and a valid timestamp, which includes time, date and timezone. To learn how to report spam so action is taken: http://spam.abuse.net/userhelp/howtocomplain.shtml To learn how to locate and interpret e-mail headers in your e-mail client: http://support.earthlink.net/support/TUTORIALS/email/mbx_interpret_headers.jsp Other useful lookup tools: http://samspade.org/ Once you have included the pertinent information needed, please resubmit your report, and include this autoresponse. Your report will then be reprocessed by our filters. However, you should expect to receive another auto-response after your resubmission is re-examined, but due to the large number of reports we receive, please understand that you may not receive a personal response. Our policies can be found at the following page: http://earthlink.net/about/policies/ Thanks, The EarthLink Abuse Staff 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=21129. 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=21129 Error message : The Parameter is incorrect when doing multipart requests (fileupload) Summary: Error message : The Parameter is incorrect when doing multipart requests (fileupload) Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] --- Description : I am using isapi_redirector2.dll and coyote connector with the usual setup. Sometimes (not everytime, maybe one in every 5 or more) I get the response error Parameter is incorrect when doing multipart requests (fileupload). In some occations, when this error has occured once, the request does not seem to be performed, the file in the upload does not reach tomcat, and the application that I use returns nulls. --- SETUP My setup is described in detail on the website http://www.reynir.net/tomcat/tomcat_IIS_service_jk2.html --- Reoccurance I've tested this with versions 2.0.2 and 2.0.1, and on at least 5 different computers in different networks with the same or very similar behaviour. The error does not occure with previous versions of the connector (isapi_redirect.dll). ERROR MESSAGES : Error log from the jklogfile : Error: [jk_worker_ajp13.c (512)]: ajp13.service() Error forwarding ajp13:ust_is:8009 1 0 Error: [jk_worker_ajp13.c (416)]: ajp13.service() ajpGetReply recoverable error 3 Error: [jk_handler_response.c (178)]: handler.response() Error sending response Error: [jk_service_iis.c (157)]: jk_ws_service_t::head, ServerSupportFunction failed Error: [jk_worker_ajp13.c (416)]: ajp13.service() ajpGetReply recoverable error 3 Error: [jk_handler_response.c (200)]: Error ajp_process_callback - write failed Error: [jk_service_iis.c (247)]: jk_ws_service_t::write, WriteClient failed For any additional information please contact me, reynir[AT]hugsmidjan.is - 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]
cvs commit: jakarta-tomcat-5 build.properties.default
remm2003/06/26 15:23:15
Modified:.build.properties.default
Log:
- Upgrade to commons-fileupload 1.0.
Revision ChangesPath
1.96 +4 -5 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.95
retrieving revision 1.96
diff -u -r1.95 -r1.96
--- build.properties.default 21 Jun 2003 13:37:21 - 1.95
+++ build.properties.default 26 Jun 2003 22:23:15 - 1.96
@@ -161,11 +161,10 @@
# - Commons FileUpload, version 1.0-20030531 or later -
-commons-fileupload.home=${base.path}/commons-fileupload-1.0-rc1
+commons-fileupload.home=${base.path}/commons-fileupload-1.0
commons-fileupload.lib=${commons-fileupload.home}
-commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0-rc1.jar
-commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz
-
+commons-fileupload.jar=${commons-fileupload.lib}/commons-fileupload-1.0.jar
+commons-fileupload.loc=http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0.tar.gz
# - Java Management Extensions (JMX), JMX RI 1.0.1 or later or MX4J 1.1 or
later -
jmx.home=${base.path}/mx4j-1.1.1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL typo in build.properties.
Uday Subbarayan wrote: Hi, I just now downloaded the tomcat-5 src and when i try to build, i got a build error for the wrong url- http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz This should be changed to - http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0-rc1.tar.gz The URL just changed, actually, and I've updated build.properties. You should get the 1.0 release instead of the RC. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL typo in build.properties.
Remy, This is the first time i am building from src and i checkout the 'jakarta-tomcat-5' module and created a new directory and followed the instruction in the 'BUILDING.txt'. I just typed 'ant' and didn't do anything different.. I guess to get the 1.0 release, this also should be changed inthe build.xml and not myself, right? Thanks, -Uday. Remy Maucherat wrote: Uday Subbarayan wrote: Hi, I just now downloaded the tomcat-5 src and when i try to build, i got a build error for the wrong url- http://www.apache.org/dist/jakarta/commons/fileupload/commons-fileupload-1.0-rc1.tar.gz This should be changed to - http://www.apache.org/dist/jakarta/commons/fileupload/binaries/commons-fileupload-1.0-rc1.tar.gz The URL just changed, actually, and I've updated build.properties. You should get the 1.0 release instead of the RC. Remy - 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]
Linda S. Gallagher/0R/Caterpillar is out of the office.
I will be out of the office starting 26Jun2003 and will not return until 2Jul2003. I will respond to your message when I return. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/apache13 Makefile.apxs.in
yoavs 2003/06/26 16:43:01
Modified:jk/native2/server/apache13 Makefile.apxs.in
Log:
Made C_FILES include jk_service_apache13.c (in addition to previous mod_jk2.c)
for bug 15771
Revision ChangesPath
1.6 +2 -1
jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.apxs.in
Index: Makefile.apxs.in
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/apache13/Makefile.apxs.in,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Makefile.apxs.in 4 Jun 2002 10:33:44 - 1.5
+++ Makefile.apxs.in 26 Jun 2003 23:43:01 - 1.6
@@ -8,6 +8,7 @@
COMMON_C_FILES := $(wildcard ${JK_DIR}/common/*.c )
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+C_FILES=jk_service_apache13_c mod_jk2_c
JK=../../common/
JKINC=../../include/
@@ -18,7 +19,7 @@
all: mod_jk2.so
mod_jk2.so:
- $(APXS) -c -o $@ -Wc,${JK_INCL} ${APR_CFLAGS} ${APR_LDFLAGS} ${JAVA_INCL}
mod_jk2.c ${COMMON_C_FILES}
+ $(APXS) -c -o $@ -Wc,${JK_INCL} ${APR_CFLAGS} ${APR_LDFLAGS} ${JAVA_INCL}
${C_FILES} ${COMMON_C_FILES}
clean:
rm -f *.o *.so
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
billbarker2003/06/26 19:54:18
Modified:jk/native/common jk_uri_worker_map.c jk_uri_worker_map.h
Log:
Fix problem with URLs that contain //.
This is essentially what Apache/httpd does in location_walk.
Reported by: Palle Girgensohn [EMAIL PROTECTED]
Revision ChangesPath
1.15 +32 -7 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- jk_uri_worker_map.c 21 Apr 2002 22:57:11 - 1.14
+++ jk_uri_worker_map.c 27 Jun 2003 02:54:17 - 1.15
@@ -453,6 +453,32 @@
return JK_FALSE;
}
+void jk_no2slash(char *name)
+{
+char *d, *s;
+
+s = d = name;
+
+#if defined(WIN32)
+/* Check for UNC names. Leave leading two slashes. */
+if (s[0] == '/' s[1] == '/')
+*d++ = *s++;
+#endif
+
+while (*s) {
+if ((*d++ = *s) == '/') {
+do {
+++s;
+} while (*s == '/');
+}
+else {
+++s;
+}
+}
+*d = '\0';
+}
+
+
char *map_uri_to_worker(jk_uri_worker_map_t *uw_map,
const char *uri,
jk_logger_t *l)
@@ -464,17 +490,16 @@
unsigned i;
unsigned best_match = -1;
unsigned longest_match = 0;
-char * clean_uri = NULL;
-char *url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);
+char * clean_uri = jk_pool_strdup(uw_map-tp,uri);
+char *url_rewrite = strstr(clean_uri, JK_PATH_SESSION_IDENTIFIER);
if(url_rewrite) {
-clean_uri = jk_pool_strdup(uw_map-tp,uri);
-url_rewrite = strstr(clean_uri, JK_PATH_SESSION_IDENTIFIER);
*url_rewrite = '\0';
-uri = clean_uri;
}
+jk_no2slash(clean_uri);
+uri = clean_uri;
- jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s'\n, uri);
+jk_log(l, JK_LOG_DEBUG, Attempting to map URI '%s'\n, uri);
for(i = 0 ; i uw_map-size ; i++) {
uri_worker_record_t *uwr = uw_map-maps[i];
1.6 +3 -1 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.h
Index: jk_uri_worker_map.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- jk_uri_worker_map.h 4 Dec 2001 19:44:23 - 1.5
+++ jk_uri_worker_map.h 27 Jun 2003 02:54:17 - 1.6
@@ -95,6 +95,8 @@
int uri_worker_map_close(jk_uri_worker_map_t *uw_map,
jk_logger_t *l);
+void jk_no2slash(char *name);
+
char *map_uri_to_worker(jk_uri_worker_map_t *uw_map,
const char *uri,
jk_logger_t *l);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
billbarker2003/06/26 20:06:43
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Clean up AutoConfig to better handle //.
Revision ChangesPath
1.39 +6 -4 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- mod_jk.c 11 Jun 2003 16:53:06 - 1.38
+++ mod_jk.c 27 Jun 2003 03:06:43 - 1.39
@@ -1840,15 +1840,17 @@
r-handler = ap_pstrdup(r-pool, JK_HANDLER);
ap_table_setn(r-notes, JK_WORKER_ID, worker);
} else if(conf-alias_dir != NULL) {
+char *clean_uri = ap_pstrdup(r-pool, r-uri);
+ap_no2slash(clean_uri);
/* Automatically map uri to a context static file */
jk_log(l, JK_LOG_DEBUG,
mod_jk::jk_translate, check alias_dir: %s\n,conf-alias_dir);
-if (strlen(r-uri) 1) {
+if (strlen(clean_uri) 1) {
/* Get the context directory name */
char *context_dir = NULL;
char *context_path = NULL;
char *child_dir = NULL;
-char *index = r-uri;
+char *index = clean_uri;
char *suffix = strchr(index+1,'/');
if( suffix != NULL ) {
int size = suffix - index;
@@ -1885,7 +1887,7 @@
if( context_path != NULL ) {
DIR *dir = ap_popendir(r-pool,context_path);
if( dir != NULL ) {
-char *escurl = ap_os_escape_path(r-pool, r-uri, 1);
+char *escurl = ap_os_escape_path(r-pool, clean_uri, 1);
char *ret =
ap_pstrcat(r-pool,conf-alias_dir,escurl,NULL);
ap_pclosedir(r-pool,dir);
/* Add code to verify real path ap_os_canonical_name */
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
billbarker2003/06/26 20:10:44
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Port from apache-1.3
Revision ChangesPath
1.80 +6 -4 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.79
retrieving revision 1.80
diff -u -r1.79 -r1.80
--- mod_jk.c 18 Jun 2003 15:48:14 - 1.79
+++ mod_jk.c 27 Jun 2003 03:10:43 - 1.80
@@ -2280,16 +2280,18 @@
return OK;
} else if(conf-alias_dir != NULL) {
+char *clean_uri = ap_pstrdup(r-pool, r-uri);
+ap_no2slash(clean_uri);
/* Automatically map uri to a context static file */
jk_log(conf-log, JK_LOG_DEBUG,
mod_jk::jk_translate, check alias_dir: %s\n,
conf-alias_dir);
-if (strlen(r-uri) 1) {
+if (strlen(clean_uri) 1) {
/* Get the context directory name */
char *context_dir = NULL;
char *context_path = NULL;
char *child_dir = NULL;
-char *index = r-uri;
+char *index = clean_uri;
char *suffix = strchr(index+1,'/');
if( suffix != NULL ) {
int size = suffix - index;
@@ -2327,7 +2329,7 @@
finfo.filetype = APR_NOFILE;
apr_stat(finfo,context_path,APR_FINFO_TYPE,r-pool);
if( finfo.filetype == APR_DIR ) {
-char *escurl = ap_os_escape_path(r-pool, r-uri, 1);
+char *escurl = ap_os_escape_path(r-pool, clean_uri, 1);
char *ret =
ap_pstrcat(r-pool,conf-alias_dir,escurl,NULL);
/* Add code to verify real path ap_os_canonical_name */
if( ret != NULL ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
