DO NOT REPLY [Bug 36895] New: - get_most_suitable_worker is called twice for a single request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36895. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36895 Summary: get_most_suitable_worker is called twice for a single request Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The function get_most_suitable_worker in jk_lb_worker.c is called twice for each request. jk_handler selects the worker returned from the first called function . So loadbalancing is not perfect. ( in mod_jk version 1.2.14 ) Consider we have two loadbalancer workers tomcat1 and tomcat2 . request1 -- jk_handler -- tomcat1 ( returned from get_most_suitable_worker) -- tomcat2 ( returned from get_most_suitable_worker) request2 -- jk_handler -- tomcat1 ( returned from get_most_suitable_worker) -- tomcat2 ( returned from get_most_suitable_worker) Here jk_handler always selects tomcat1. If we have 3 loadbalancer workers, the sequence will be like this request1 -- jk_handler -- tomcat1 -- tomcat2 request2 -- jk_handler -- tomcat3 -- tomcat1 request3 -- jk_handler -- tomcat2 -- tomcat3 Here the loadbalancing sequence will be ... tomcat1,tomcat3,tomcat2,tomcat1. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Please witch over to tomcat-user for discussion. This is not really a developer issue. === My previous comments (bugzilla) === First hints from my side: reduce to equal number of apache and tomcat instances, configure F5 with rule that sends URLs with session cookie or jsessionid in URL to the correct apache. Furthermore configure mod_jk, such that each apache sends requests without sessions to it's preferred tomcat partner. That way almost all apache processes will connect to only one tomcat. If you still need 16K apache processes per instance you are in trouble (maybe upgrade to apache 2), if you manage to handle the workload with 1K apache processes, 1K Threads in Tomcat should be OK. === Additional comments === If you don't want to reuse the connections between apache and tomcat (last ressort solution) switch over to connectors of type ajp12 (they will close the connection after each request-response cycle) or set cachesize to 0 which will use ajp13 protocol, but I think it will close connections after each request too. I hope you don't use HTTP keep alive? Also: I vaguely remember there was an experimental connector/thread pool implementation with asynchroneous features. It might be, that this implementation does not need one fixed thread for each apache connection and I think it is beeing shipped with 5.5.x, but not enabled on default. Concerning this topic tomcat-dev might be the right place to ask. Rainer Remy Gendron wrote: Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too
DO NOT REPLY [Bug 36837] New: - Looking for ProxyHandler implementation of Http request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36837. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36837 Summary: Looking for ProxyHandler implementation of Http request Product: Tomcat 5 Version: Unknown Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We are looking for the ProxyHandler implementation of HTTP request handler. This will allow us to configure the Tomcat Http server as proxy server and build the application for creating the Http Tunnel This HTTP Tunnel can be used to take over a HTTP connection in order to tunnel another protocol over it -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36827] New: - Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36827. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36827 Summary: Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle. Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Native:JK AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Heres the situation as it stands today and what can be done to solve it. Ill try to keep this short. Running configuration: Running on Linux Red-Hat Ent 3 1 X F5 load balancer and hardware SSL box. 5 X Apache 1.3.33/mod_jk 1.2.14 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too many web server children are created to serve the company load. Thus, many different routes can be taken by requests targeted to our application, keeping all the connection alive. 12. We tried really small recycle_timeout values (e.g. 20) with no effect. A netstat reveals that connections remain ESTABLISHED. 13. The maxRequestsPerChild setting is set to 0 in PROD. It means that Apache child processes will never die, unless you reach the maxSpareServers value. Thus, at least 100 connections per web server will always remain actively connected to Tomcat. A 0 value would at least guarantee that a child process would eventually die, freeing
Need an option to severe socket connections between mod_jk and ajp connector after request/response cycle.
Hi all, Here's the situation as it stands today and what can be done to solve it. I'll try to keep this short. Running configuration: * Running on Linux Red-Hat Ent 3 * 1 X F5 load balancer and hardware SSL box. * 5 X Apache 1.3.33/mod_jk 1.2.14 * 6 X JBoss 4.0.0/Tomcat 5.0.28 using the AJP13 connector. * Oracle 9i Our production environment hosts a number of applications, each with different load and usage patterns. Our problem comes from the fact that it is difficult to find a web farm configuration that will satisfy every application. For reasons I will not explain here, we cannot have a dedicated web farm for each application. This is what we think is happening in our production environment based on tests ran in UAT (User Acceptance Tests) and literature from the Apache and Tomcat products. This is all pretty new to us so if someone can provide hard facts, you are more than welcome. 1. The 1.3 generation of Apache web servers will spawn a child process to handle an HTTP request. Only one HTTP request at a time can be processed by that child. 2. As the load increases on the web server, additional child processes will be spawned to concurrently serve the requests. There is a default limit to how many child processes can be forked. That limit defaults to 256 but has been changed in production to 16384. This is the MaxClients directive. It seems that production really needs the 16384 value instead of the 256 default. With 256, our web servers were rejecting connections and could not support the load generated by all of our clients. 3. To prevent latency, Apache will maintain a maximum of 100 spare child processes alive. Spare means that they are not serving requests. Once reached, that number of spare servers does not seem to decrease. This is the number we see in our tests in UAT where 201 threads remain active in Tomcat. This is the 100 spare children connections * 2 web server plus accept() thread. 4. If a request needs to be forwarded to Tomcat/JBoss (dynamic pages), the child process mod_jk module will instantiate a socket connection to the ajp13 connector in Tomcat. 5. Tomcat will accept the connection and create a thread to serve it. Connections will be accepted up to a concurrent maximum of 1200. This upper value has been set by us. 6. Tomcat will reject connections when the maximum is reached. JBoss 4.0.0 has a known issue where the server will die when the maximum is reached. This has been fixed in 4.0.2. 7. A connection could potentially be recycled in mod_jk (recycle_timeout) if no activity occurs thru the connection. However, any requests to Tomcat from any user session-bound to that Tomcat instance could go thru the connection, thus keeping it active. Recycling does not seem to occur. We use a recycle_timeout value of 300. 8. The fact that the production web servers can potentially serve up to 16384 concurrent requests make it possible for a web server to instantiate an almost infinite number of connections to Tomcat and nuke it. 9. Tomcat can then become overloaded with connections. If a valid HTTP request comes thru Apache and is routed to a child process that has not yet made a connection to Tomcat, the connection could be impossible if Tomcat has already accepted its 1200 limit. 10. In that case, mod_jk could potentially fail over to another Tomcat. The user would however loose his session. 11. The recycle_timeout and cache_size options are of no use to us because too many web server children are created to serve the company load. Thus, many different routes can be taken by requests targeted to our application, keeping all the connection alive. 12. We tried really small recycle_timeout values (e.g. 20) with no effect. A netstat reveals that connections remain ESTABLISHED. 13. The maxRequestsPerChild setting is set to 0 in PROD. It means that Apache child processes will never die, unless you reach the maxSpareServers value. Thus, at least 100 connections per web server will always remain actively connected to Tomcat. A 0 value would at least guarantee that a child process would eventually die, freeing Tomcat connections and releasing back leaked memory to the OS. It's hard to see a path out of this one. One solution would be to reduce the MaxClients Apache config back to 256. This would mean that a single instance of Tomcat would not be hit by more than 256 * 5 = 1280 (5 is the web farm size) connections. Our current jvm settings (heap + thread stack sizes) would allow us to do it. We would also need to bump our current 1200 limit a bit higher. However, this solution if not compatible with other applications which have really high loads. Second option would be to patch mod_jk so that connections are dropped as soon as the response has been received from Tomcat. Drawbacks include preventing us from upgrading to new releases (unless we re-apply the modifications), introduce
Problems Parsing Request Paramers
First off, I apologize for the cross-post. I posted this same message in the User's mailing list with no replies. So, my hope is that one of you developers may have some insight into the problem that I'm having. Certain users of my website are having issues with respect to submitting a form on a page. Not all users are experiencing this problem, and I've yet to replicate it myself so it makes the situation even more complex. I have an icking suspicion that its related to the user's browser, but I've tested on the same browser version/subversion without a glitch. Here's the scenario: 1) User goes to page. 2) User fills out form. 3) User clicks submit. 4) JSP page then performs sanity checks against submitted data. In the event of a failure on the sanity checks, page is redirected back to previous page. Simple enough. Well, users are filling out the form and clicking submit with valid infromation, yet when I parse the parameters out of the request, I'm finding none of the form values from the previous page. I then decided to investigate further and log out all request information in the event that these sanity checks fail. The following is what I logged out: - Attributes: javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5] javax.servlet.request.key_size = [128] javax.servlet.request.ssl_session = [433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80] Parameters: Cookies: JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE] contact_value = [ABC] duplicate_type = [None] duplicate_time = [] mortgage = [] lender_id_label = [] title_alternative = [] can_place_orders = [Y] flood_default = [126] can_cancel_lol = [N] contact_label = [] lender_id_value = [ABC] census = [] loan_no_label = [] delivery_method = [Online] apprasail = [] delivery_address = [] title = [] Headers: accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, application/x-shockwave-flash, */*] referer = [https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applicant 2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFixDi r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone= applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone= applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro ductFlood=Yesapplicant2Fname=Doe] accept-language = [en-us] content-type = [application/x-www-form-urlencoded] accept-encoding = [gzip, deflate] user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)] host = [WEBSITE_DOMAIN] connection = [Keep-Alive] cache-control = [no-cache] cookie = [JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE; contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=; lender_id_label=; title_alternative=; can_place_orders=Y; flood_default=126; can_cancel_lol=N; contact_label=; lender_id_value=ABC; census=; can_view_insurance_tracking=N; loan_no_label=; delivery_method=Online; apprasail=; delivery_address=; title=] content-length = [0] - There are many interesting things about this request. First, the content-length is 0. Not sure how this could happen...error in browser?? Second, and the most intriguing...Notice the referer entry. The referer entry actually contains all relevant information that I needed in order to process this request, yet if you look at what parameters I was actually able to parse off this request you will see...NONE. I'm stumped. Anybody else seen this before? Environment: JDK 1.4.2_08 Tomcat 5.5.9 ___ Jeremy Nix Senior Application Developer Southwest Financial Services, LTD. (513) 621-6699 x1158 www.sfsltd.com
Re: Problems Parsing Request Paramers
Hi, Could it be the referer URL is too long, causing the query string to be ignored or dropped? There's a limit (2048 characters, I think?) on GET requests in some browsers. But actually, you're seeing this on the server, so I'm not sure. Can you try testing with less parameters or an otherwise shorter query string? Yoav --- Jeremy Nix [EMAIL PROTECTED] wrote: First off, I apologize for the cross-post. I posted this same message in the User's mailing list with no replies. So, my hope is that one of you developers may have some insight into the problem that I'm having. Certain users of my website are having issues with respect to submitting a form on a page. Not all users are experiencing this problem, and I've yet to replicate it myself so it makes the situation even more complex. I have an icking suspicion that its related to the user's browser, but I've tested on the same browser version/subversion without a glitch. Here's the scenario: 1) User goes to page. 2) User fills out form. 3) User clicks submit. 4) JSP page then performs sanity checks against submitted data. In the event of a failure on the sanity checks, page is redirected back to previous page. Simple enough. Well, users are filling out the form and clicking submit with valid infromation, yet when I parse the parameters out of the request, I'm finding none of the form values from the previous page. I then decided to investigate further and log out all request information in the event that these sanity checks fail. The following is what I logged out: - Attributes: javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5] javax.servlet.request.key_size = [128] javax.servlet.request.ssl_session = [433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80] Parameters: Cookies: JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE] contact_value = [ABC] duplicate_type = [None] duplicate_time = [] mortgage = [] lender_id_label = [] title_alternative = [] can_place_orders = [Y] flood_default = [126] can_cancel_lol = [N] contact_label = [] lender_id_value = [ABC] census = [] loan_no_label = [] delivery_method = [Online] apprasail = [] delivery_address = [] title = [] Headers: accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, application/x-shockwave-flash, */*] referer = [https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applicant 2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFixDi r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone= applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone= applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro ductFlood=Yesapplicant2Fname=Doe] accept-language = [en-us] content-type = [application/x-www-form-urlencoded] accept-encoding = [gzip, deflate] user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)] host = [WEBSITE_DOMAIN] connection = [Keep-Alive] cache-control = [no-cache] cookie = [JSESSIONID=FCB31837FFBD2C0D9F986C42B698BADE; contact_value=ABC; duplicate_type=None; duplicate_time=; mortgage=; lender_id_label=; title_alternative=; can_place_orders=Y; flood_default=126; can_cancel_lol=N; contact_label=; lender_id_value=ABC; census=; can_view_insurance_tracking=N; loan_no_label=; delivery_method=Online; apprasail=; delivery_address=; title=] content-length = [0] - There are many interesting things about this request. First, the content-length is 0. Not sure how this could happen...error in browser?? Second, and the most intriguing...Notice the referer entry. The referer entry actually contains all relevant information that I needed in order to process this request, yet if you look at what parameters I was actually able to parse off this request you will see...NONE. I'm stumped. Anybody else seen this before? Environment: JDK 1.4.2_08 Tomcat 5.5.9 ___ Jeremy Nix Senior Application Developer Southwest Financial Services, LTD. (513) 621-6699 x1158 www.sfsltd.com
RE: Problems Parsing Request Paramers
The original referer variable was a little over 1K chars, so I don't believe that I'm pushing that limit quite yet. As for recreating...I cannot. I wish I could. In order for me to cut down the # of parameters, I'd have to modify the workflow process which could potentially aggitate our users. I will try this locally, but I'm almost certain that my testing will be futile since I've yet to recreate the scenario. Any other ideas? I did speak with someone over the phone today who contacted me regarding this post. It seems as though they have experienced the same problem with Tomcat 4 and 5. He seemed to believe it was related to load. I know that our website typically operates at roughly 80 users at a time. At our peak, 200 users. So, I'm not so sure it is related to load, but I'm going to do some further investigating in our test environment with a load tester to see if I can recreate the problem. ___ Jeremy Nix Senior Application Developer Southwest Financial Services, LTD. (513) 621-6699 x1158 www.sfsltd.com -Original Message- From: Yoav Shapira [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 27, 2005 2:06 PM To: Tomcat Developers List Subject: Re: Problems Parsing Request Paramers Hi, Could it be the referer URL is too long, causing the query string to be ignored or dropped? There's a limit (2048 characters, I think?) on GET requests in some browsers. But actually, you're seeing this on the server, so I'm not sure. Can you try testing with less parameters or an otherwise shorter query string? Yoav --- Jeremy Nix [EMAIL PROTECTED] wrote: First off, I apologize for the cross-post. I posted this same message in the User's mailing list with no replies. So, my hope is that one of you developers may have some insight into the problem that I'm having. Certain users of my website are having issues with respect to submitting a form on a page. Not all users are experiencing this problem, and I've yet to replicate it myself so it makes the situation even more complex. I have an icking suspicion that its related to the user's browser, but I've tested on the same browser version/subversion without a glitch. Here's the scenario: 1) User goes to page. 2) User fills out form. 3) User clicks submit. 4) JSP page then performs sanity checks against submitted data. In the event of a failure on the sanity checks, page is redirected back to previous page. Simple enough. Well, users are filling out the form and clicking submit with valid infromation, yet when I parse the parameters out of the request, I'm finding none of the form values from the previous page. I then decided to investigate further and log out all request information in the event that these sanity checks fail. The following is what I logged out: -- -- - Attributes: javax.servlet.request.cipher_suite = [SSL_RSA_WITH_RC4_128_MD5] javax.servlet.request.key_size = [128] javax.servlet.request.ssl_session = [433162398579970fee9289baa9ac832b8558dcc409382f62cb67a3499b80] Parameters: Cookies: JSESSIONID = [FCB31837FFBD2C0D9F986C42B698BADE] contact_value = [ABC] duplicate_type = [None] duplicate_time = [] mortgage = [] lender_id_label = [] title_alternative = [] can_place_orders = [Y] flood_default = [126] can_cancel_lol = [N] contact_label = [] lender_id_value = [ABC] census = [] loan_no_label = [] delivery_method = [Online] apprasail = [] delivery_address = [] title = [] Headers: accept = [image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, application/x-shockwave-flash, */*] referer = [https://WEBSITE_URL/CreateOrder.jsp?applicant2HomePhone=streetName=Ma in+Stapplicant2WorkPhone=applicantOtherPhone=ownerEstimate=applica in+nt 2WorkPhone2=revisionOf=applicantWorkPhoneExtension=unitType=preFix Di r=Eapplicant2OtherPhoneAreaCode=applicantOtherPhone2=applicantMname=L skipstep=nonezip4=applicant2HomePhoneAreaCode=applicant2OtherPhone= applicantLname=DoestreetNum=applicantHomePhoneAreaCode=zip=40845pass code=HomeorderHeaderGeneralNotes=applicantHomePhone2=propertyLoanNumb er=productTitle=applicantFname=Johnapplicant2WorkPhoneExtension=appl icant2WorkPhoneAreaCode=applicant2Mname=JunitNumber=applicantWorkPhon eAreaCode=postFixDir=productAppraisal=propertyParcelNumber=applicant WorkPhone2=applicantOtherPhoneAreaCode=city=HulenapplicantHomePhone= applicantWorkPhone=applicant2Lname=Janeapplicant2OtherPhone2=applican t2HomePhone2=streetType=state=KYcontactId=10productMortgagePrep=pro ductFlood=Yesapplicant2Fname=Doe] accept-language = [en-us] content-type = [application/x-www-form-urlencoded] accept-encoding = [gzip, deflate] user-agent = [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322
Re: Problems Parsing Request Paramers
Yoav Shapira wrote: Hi, Could it be the referer URL is too long, causing the query string to be ignored or dropped? There's a limit (2048 characters, I think?) on GET requests in some browsers. But actually, you're seeing this on the server, so I'm not sure. Can you try testing with less parameters or an otherwise shorter query string? I've seen this sort of thing too, but I thought it was 255 chars. From RFC2616 section 3.2.1: Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. Not quite set in stone, but a good general hint to avoid long URLs. Rick -- Servlet v2.4 container in a single 155KB jar file ? Try Winstone (http://winstone.sourceforge.net/) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-18 20:52 --- Same problem here. Please let us know how we can help debugging that issue. Thanks Alex -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-19 00:48 --- (In reply to comment #10) Same problem here. Please let us know how we can help debugging that issue. Thanks Alex It's pretty clear what is happening: mod_jk isn't sending the POST body before the Tomcat-configured connectionTimeout has been reached. What isn't clear is why. In the first dump example, the worker in the JSESSIONID cookie isn't in the list (there are also some decoding problems, but they shouldn't affect Tomcat). In the second dump example, mod_jk has decided to send the request to a different worker than the one in the cookie for some reason. Otherwise, they are perfectly normal POST request records. Probably, somebody is going to have to be able to reproduce this with 'JkLogLevel debug' (or even 'JkLogLevel trace' :) to get some idea why the POST body wasn't sent. As an aside, Tomcat 5.5.11+ won't have this particular error, but it is also extremely unlikely to actually work. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36655] New: - mod_jk 1.2.12+ does not submit correct request port number to tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36655 Summary: mod_jk 1.2.12+ does not submit correct request port number to tomcat Product: Tomcat 4 Version: 4.1.31 Platform: Other OS/Version: Solaris Status: NEW Severity: major Priority: P2 Component: Connector:JK/AJP AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In our infrastructure a https request is handled in this way: https request(port 443) - SSL-accelerator (Nortel/Alteon) - decrypted request port 50443 - Apache-2.0.53 listening on 80, 55443 using virtual hosts - mod_jk 1.2.12, AJP13 port 8200 - Tomcat 4.1.31 with application The application checks wether a request hit the Apache2 on port 55443 or 80. If the port was 80, a warning message is sent back to the client about unencrypted traffic. Now we got the warning message also with a request on port 55443. mod_jk logs in debug mode: [Fri Sep 09 11:28:20 2005] [22238:0006] [debug] init_ws_service::mod_jk.c (510): Service pro tocol=HTTP/1.1 method=GET host=(null) addrr=192.168.70.130 name=jportal1-riat-p.bap.fiducia. de port=80 auth=(null) user=(null) laddr=10.253.52.65 raddr=192.168.70.130 So there is a wrong port number sent to Tomcat/application. I have traced the problem down to jakarta-tomcat-connectors-1.2.12-src/jk/native/apache-2.0/mod_jk.c where I've found the following: /* get the real port (otherwise redirect failed) */ /* XXX: use apache API for getting server port * * Pre 1.2.7 versions used: * s-server_port = r-connection-local_addr-port; */ s-server_port = ap_get_server_port(r); So I uncommented the old code and commented the new line: /* get the real port (otherwise redirect failed) */ /* XXX: use apache API for getting server port * * Pre 1.2.7 versions used: */ s-server_port = r-connection-local_addr-port; /*s-server_port = ap_get_server_port(r); */ Now the mod_jk log says: [Fri Sep 09 13:15:10 2005] [22238:0006] [debug] init_ws_service::mod_jk.c (510): Service pro tocol=HTTP/1.1 method=GET host=(null) addrr=192.168.70.130 name=jportal1-riat-p.bap.fiducia. de port=55443 auth=(null) user=(null) laddr=10.253.52.65 raddr=192.168.70.130 The port is now sent correctly to Tomcat/application. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36655] - mod_jk 1.2.12+ does not submit correct request port number to tomcat
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36655 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-14 14:17 --- Hi, You should supply the port with ServerName. This is from ap_get_server_port: /* With UseCanonicalName on (and in all versions prior to 1.3) * Apache will use the hostname and port specified in the * ServerName directive to construct a canonical name for the * server. (If no port was specified in the ServerName * directive, Apache uses the port supplied by the client if * any is supplied, and finally the default port for the protocol * used. So, since probably nothing matched, the 80 (as default) was used. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 23:39 --- I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? Sep 8, 2005 2:55:53 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Unknown Source) 12 34 0d a4 02 04 00 08 48 54 54 50 2f 31 2e 30 | .4.?HTTP/1.0 00 00 1f 2f 69 64 6d 2f 75 73 65 72 2f 47 45 54 | .../idm/user/GET 53 70 72 6f 63 65 73 73 4c 61 75 6e 63 68 2e 6a | SprocessLaunch.j 73 70 00 00 0b 33 2e 33 34 2e 32 32 31 2e 37 31 | sp...3.34.221.71 00 00 0b 33 2e 33 34 2e 32 32 31 2e 37 31 00 00 | ...3.34.221.71.. 13 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 | .idm.treasury.ge 2e 63 6f 6d 00 01 bb 01 00 22 a0 01 00 a4 69 6d | .com..?..?..?im 61 67 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 | age/gif, image/x 2d 78 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f | -xbitmap, image/ 6a 70 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 | jpeg, image/pjpe 67 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 | g, application/x 2d 73 68 6f 63 6b 77 61 76 65 2d 66 6c 61 73 68 | -shockwave-flash 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 6e | , application/vn 64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 70 6c | d.ms-excel, appl 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 2d 70 | ication/vnd.ms-p 6f 77 65 72 70 6f 69 6e 74 2c 20 61 70 70 6c 69 | owerpoint, appli 63 61 74 69 6f 6e 2f 6d 73 77 6f 72 64 2c 20 2a | cation/msword, * 2f 2a 00 a0 04 00 05 65 6e 2d 75 73 00 a0 06 00 | /*.?...en-us.?.. 0a 4b 65 65 70 2d 41 6c 69 76 65 00 a0 0b 00 13 | .Keep-Alive.?... 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 2e | idm.treasury.ge. 63 6f 6d 00 a0 0d 00 3a 68 74 74 70 73 3a 2f 2f | com.?..:https:// 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 2e | idm.treasury.ge. 63 6f 6d 2f 69 64 6d 2f 47 45 54 53 72 65 71 75 | com/idm/GETSrequ 65 73 74 2f 6e 65 77 52 65 71 75 65 73 74 2e 6a | est/newRequest.j 73 70 00 a0 0e 00 4a 4d 6f 7a 69 6c 6c 61 2f 34 | sp.?..JMozilla/4 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 20 | .0 (compatible; 4d 53 49 45 20 36 2e 30 3b 20 57 69 6e 64 6f 77 | MSIE 6.0; Window 73 20 4e 54 20 35 2e 31 3b 20 53 56 31 3b 20 2e | s NT 5.1; SV1; . 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 32 | NET CLR 1.1.4322 29 00 a0 09 04 57 53 4d 53 45 53 53 49 4f 4e 3d | ).?..WSMSESSION= 52 59 65 4d 37 34 78 42 62 6d 48 62 4e 47 65 4c | RYeM74xBbmHbNGeL 4d 4a 66 45 58 41 72 47 7a 41 69 4d 76 35 34 56 | MJfEXArGzAiMv54V 50 38 55 54 48 74 78 33 53 75 50 64 4d 35 48 2f | P8UTHtx3SuPdM5H/ 56 61 36 65 38 76 6a 48 48 41 57 35 35 4c 47 49 | Va6e8vjHHAW55LGI 72 6e 5a 73 46 35 54 50 63 76 4d 6d 6e 56 54 72 | rnZsF5TPcvMmnVTr 6d 78 42 47 75 4e 45 38 71 74 71 31 70 46 38 70 | mxBGuNE8qtq1pF8p 61 37 56 2f 52 62 30 4e 56 75 7a 30 67 49 50 41 | a7V/Rb0NVuz0gIPA 41 66 41 62 65 2b 4f 6f 38 73 71 4e 79 70 34 2f | AfAbe+Oo8sqNyp4/ 79 6b 30 54 55 52 41 36 63 76 57 47 4a 71 69 70 | yk0TURA6cvWGJqip 72 53 6a 38 74 70 52 55 65 52 6c 75 6d 46 6d 56 | rSj8tpRUeRlumFmV 4f 58 6e 49 34 49 58 4e 47 66 66 6e 61 53 49 76 | OXnI4IXNGffnaSIv 55 78 77 6e 6f 57 46 41 43 4d 50 57 4e 46 75 4b | UxwnoWFACMPWNFuK 6a 41 6d 33 6b 75 55 37 49 73 4f 51 6b 6a 2f 64 | jAm3kuU7IsOQkj/d 61 37 41 33 53 52 77 4a 35 34 4f 73 55 45 4e 51 | a7A3SRwJ54OsUENQ 47 32 4f 6b 6d 38 71 54 74 54 4b 77 44 30 61 74 | G2Okm8qTtTKwD0at 34 71 64 6a 54 4d 54 55 6b 55 44 47 6d 53 6c 34 | 4qdjTMTUkUDGmSl4 36 69 42 4d 33 70 62 76 32 5a 52 39 35 49 45 2b | 6iBM3pbv2ZR95IE+ 72 41 4f 43 39 44 41 35 37 49 36 6b 55 74 65 4a | rAOC9DA57I6kUteJ 30 4f 46 44 46 64 53 75 39 72 42 73 59 75 47 62 | 0OFDFdSu9rBsYuGb 79 74 42 4a 34 33 5a 2f 62 56 33 61 4b 58 73 79 | ytBJ43Z/bV3aKXsy 76 69 4e 2b 33 30 68 50 54 76 31 46 49 54 56 46 | viN+30hPTv1FITVF 69 50 66 55 6e 57 44
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 02:31 --- (In reply to comment #3) I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? I certain that you won't see this exact error in 5.5.11+ ;-). There is nothing here to indicate a problem with Tomcat. It's possible that there is something in the mod_jk logs that indicates why mod_jk decided to drop the connection to Tomcat. However there is certainly not enough information here to even believe that there is anything here that requires fixing. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-09-07 20:18 --- I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 10:43 --- cping/cpong are handled in ajp_connect_to_endpoint -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-02 11:33 ---
(In reply to comment #1)
cping/cpong are handled in ajp_connect_to_endpoint
ajp_connect_to_endpoint sends a ping to validate the connection if
connect_timeout has been set.
However, if you haven't set connect_timeout and you've set prepost_timeout
(asking for a ping to be sent before every request), no ping will be sent before
the first request.
Here's an alternative patch (against mod_jk 1.2.14) that I hope better
illustrates what I'm trying to say:
START OF PATCH
--- jk_ajp_common.c 2005-09-02 10:22:18.446771900 +0100
+++ jk_ajp_common.c_modified2005-09-02 10:25:36.164484700 +0100
@@ -881,6 +881,11 @@
ae-worker-connect_timeout, l);
JK_TRACE_EXIT(l);
return rc;
+} else if (ae-worker-prepost_timeout 0) {
+rc = ajp_handle_cping_cpong (ae,
+ae-worker-prepost_timeout, l);
+JK_TRACE_EXIT(l);
+return rc;
}
JK_TRACE_EXIT(l);
return JK_TRUE;
END OF PATCH
I understand that I can get the same behaviour by setting connect_timeout to
the same value as prepost_timeout, but setting prepost_timeout should be enough
to have a ping sent before every request.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385
--- Additional Comments From [EMAIL PROTECTED] 2005-09-02 11:46 ---
Well I prefer :
/* no need to handle cping/cpong here since it should be at connection
time */
-if (ajp_connect_to_endpoint(ae, l) == JK_TRUE) {
+if ((ajp_connect_to_endpoint(ae, l) == JK_TRUE)
+((ae-worker-connect_timeout 0)
+((ae-worker-prepost_timeout 0)) ||
+(ajp_handle_cping_cpong(ae, ae-worker-prepost_timeout, l)
+== JK_TRUE))) {
/*
* After we are connected, each error that we are going to
* have is probably unrecoverable
Don't send a ping before request if a ping as been send during connect !
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385
--- Additional Comments From [EMAIL PROTECTED] 2005-09-02 12:05 ---
Index: jk_ajp_common.c
===
RCS file:
/home/cvs//jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.119
diff -u -r1.119 jk_ajp_common.c
--- jk_ajp_common.c 26 May 2005 14:36:14 - 1.119
+++ jk_ajp_common.c 2 Sep 2005 10:04:17 -
@@ -1227,9 +1227,20 @@
JK_TRACE_EXIT(l);
return JK_FALSE;
}
-/* no need to handle cping/cpong here since it should be at connection
time */
+
+if ((ajp_connect_to_endpoint(ae, l) == JK_TRUE)) {
-if (ajp_connect_to_endpoint(ae, l) == JK_TRUE) {
+ /* no need to handle cping/cpong if allready sent at connection
time */
+
+ if ((ae-worker-connect_timeout = 0)
(ae-worker-prepost_timeout 0)) {
+ if (ajp_handle_cping_cpong(ae, ae-worker-prepost_timeout, l) !=
JK_TRUE) {
+jk_log(l, JK_LOG_INFO,
+ Error sending ping pong on a fresh connection);
+JK_TRACE_EXIT(l);
+return JK_FALSE;
+ }
+ }
+
/*
* After we are connected, each error that we are going to
* have is probably unrecoverable
Here is my latest prefered patch.
BTW, I couldn't commit it (damnt eclipse)
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 12:40 --- Sending cping/cpong makes no sense if connect was successful, and it was deliberately removed from recent versions. ajp_connect_to_enpoint uses timeout (socket_timeout), and if it succeeds there is no need to try sending cping/cpong. Tomcat will either hang or simply refuse the connection if the max thread limit gets reached, so the first phase in that case will fail. IMO there is no point of sending cping/cpong if new connection is established. It makes sense only with already connected sockets where it is used to deal with broken sockets. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 13:08 --- Comments inline. (In reply to comment #5) Sending cping/cpong makes no sense if connect was successful, and it was deliberately removed from recent versions. ajp_connect_to_enpoint uses timeout (socket_timeout), and if it succeeds there is no need to try sending cping/cpong. Tomcat will either hang or simply refuse the connection if the max thread limit gets reached, so the first phase in that case will fail. I've found this behaviour (which I consider a bug) when Enhydra/Tomcat had a problem that allowed me to establish connections to the AJP port but wouldn't respond to any requests (including the first one on a fresh connection). IMO there is no point of sending cping/cpong if new connection is established. It makes sense only with already connected sockets where it is used to deal with broken sockets. But that's the sole reason for the existence of the connect_timeout property: for sending a cping/cpong after a new connection is established. What I think that is a bug is the fact that if I use only prepost_timeout and not connect_timeout, there is no cping/cpong before the first request (at least, if this is the intended behavior, a remark should be make in the documentation). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 13:54 --- (In reply to comment #5) Sending cping/cpong makes no sense if connect was successful, and it was deliberately removed from recent versions. ajp_connect_to_enpoint uses timeout (socket_timeout), and if it succeeds there is no need to try sending cping/cpong. Tomcat will either hang or simply refuse the connection if the max thread limit gets reached, so the first phase in that case will fail. I didn't agree. Even if you connect to the remote Tomcat, this one could be hang and that was the ping/pong goal, detect a zombie or hanged tomcat. I got case where the tomcat was able to do the accept but was in serious trouble at a later time, and didn't process the request. IMO there is no point of sending cping/cpong if new connection is established. It makes sense only with already connected sockets where it is used to deal with broken sockets. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 14:36 --- (In reply to comment #7) I didn't agree. Even if you connect to the remote Tomcat, this one could be hang and that was the ping/pong goal, detect a zombie or hanged tomcat. I got case where the tomcat was able to do the accept but was in serious trouble at a later time, and didn't process the request. Ok, but I don't see a way to guarantee that a Tomcat will process a request. Answering a pong right after an accept does not add much. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 14:43 --- at least you could be sure some sort of code in the request handler is still alive and running. Not a 100% guarantee of course :( -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36385 --- Additional Comments From [EMAIL PROTECTED] 2005-09-02 16:53 --- (In reply to comment #9) at least you could be sure some sort of code in the request handler is still alive and running. Yes, it means the acceptor thread has managed to allocate a processor thread. If it can't it's supposed to close the socket, though, which should indicate the Tomcat instance is down. If it does allocate the processor and starts doing things, I don't see how it can fail to send a pong back. What is the Tomcat state where there would be a problem ? (BTW, I think I've fixed the biggest AJP APR bugs, so you can test it: if your servers have resource efficiency issues, then it can't hurt) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[mod_jk1.2.14] Prepost pings are not sent before the first request (bug 36385)
Hi all, I've submitted a bug report to the ASF bugzilla but since the status of the bug hasn't changed since then (and since it is so trivial to fix) I've decided to ask you guys if I didn't follow the submitting protocol correctly or something. I've submitted a patch inline with the bug report. Best regards, Edgar Alves - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36385] New: - [mod_jk1.2.14] Prepost pings are not sent before the first request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36385
Summary: [mod_jk1.2.14] Prepost pings are not sent before the
first request
Product: Tomcat 5
Version: Unknown
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P3
Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]
Prepost pings are not sent before the first request over a new connection.
Here's a possible patch:
START OF PATCH
---
jakarta-tomcat-connectors-1.2.14.1-src-original/jk/native/common/jk_ajp_common.c
2005-05-26 15:36:14.0 +0100
+++
jakarta-tomcat-connectors-1.2.14.1-src-modified/jk/native/common/jk_ajp_common.c
2005-08-26 18:25:22.0 +0100
@@ -1229,7 +1229,11 @@
}
/* no need to handle cping/cpong here since it should be at connection
time */
-if (ajp_connect_to_endpoint(ae, l) == JK_TRUE) {
+if ((ajp_connect_to_endpoint(ae, l) == JK_TRUE)
+((ae-worker-connect_timeout 0) ||
+(!(ae-worker-prepost_timeout 0)) ||
+(ajp_handle_cping_cpong(ae, ae-worker-prepost_timeout, l)
+== JK_TRUE))) {
/*
* After we are connected, each error that we are going to
* have is probably unrecoverable
END OF PATCH
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:05 --- Created an attachment (id=15844) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15844action=view) workers.properties from mod_jk configuration -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:07 --- Created an attachment (id=15845) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15845action=view) modjk directives -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:09 --- I have attached our workers.properties file and a file jk.conf including the directives. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-02 14:29 --- (In reply to comment #3) Hmm, This seems like you are using 'application/x-www-form-urlencoded' with GET request. Can you post the full mod_jk log from the beggining of the transaction to the end for that request. There must be some errors in ajp protocol, either setting timeout too low or forbidding post requests. Hello, I have sent attachements concerning workers.properties an directives. Our application is using webservers running behind a loadbalancer. Therefore it is a little bit difficult to find the exact statement that matches the stack trace of the tomcat. But there some stack traces in our Tomcats logfile and I will sent a you a typical error sequence from a modjk log file [Mon Aug 01 18:56:03 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any moreajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:54:17 2005] [info] jk_open_socket::jk_connect.c (444): connect to 145.228.205.181:16008 failed with errno=111 [Mon Aug 01 18:54:17 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (889): Failed opening socket to (145.228.205.181:16008) with (errno=111) [Mon Aug 01 18:54:17 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Error connecting to the Tomcat process. [Mon Aug 01 18:54:17 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=2 [Mon Aug 01 18:54:17 2005] [info] jk_open_socket::jk_connect.c (444): connect to 145.228.205.181:16008 failed with errno=111 [Mon Aug 01 18:54:17 2005] [info] ajp_connect_to_endpoint::jk_ajp_common.c (889): Failed opening socket to (145.228.205.181:16008) with (errno=111) [Mon Aug 01 18:54:17 2005] [info] ajp_send_request::jk_ajp_common.c (1248): Error connecting to the Tomcat process. [Mon Aug 01 18:54:17 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=3 [Mon Aug 01 18:54:17 2005] [error] ajp_service::jk_ajp_common.c (1758): Error connecting to tomcat. Tomcat is probably not started or is listening on the wrong port. worker=ASTPPRMB failed [Mon Aug 01 18:54:17 2005] [info] service::jk_lb_worker.c (662): service failed, worker ASTPPRMB is in error state [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any more (errno=-1) [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:09 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 13 is not connected any more (errno=-1) [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:53 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 7 is not connected any more (errno=-1) [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:09 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:09 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1178): Socket 13 is not connected any more (errno=-1) [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1202): Error sending request. Will try another pooled connection [Mon Aug 01 18:55:53 2005] [info] ajp_send_request::jk_ajp_common.c (1225): All endpoints are disconnected or dead [Mon Aug 01 18:55:53 2005] [info] ajp_service::jk_ajp_common.c (1749): Sending request to tomcat failed, recoverable operation attempt=1 [Mon Aug 01 18:55:57 2005] [info] ajp_process_callback::jk_ajp_common.c (1384): Connection aborted or network problems [Mon Aug 01 18:55:57 2005] [info] ajp_service::jk_ajp_common.c (1731): Receiving from tomcat failed, because
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 10:36 --- Hello, thank you very much for your help so far. We have now installed newest mod_jk version (1.2.14) but the bug still exists. Does the newest version include the bugfix already ? If yes it would be very kind if you would reinvestigate: 29.07.2005 15:55:00 org.apache.jk.common.HandlerRequest invoke SCHWERWIEGEND: Error decoding request java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:598) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:535) at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:247) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Thread.java:595) 12 34 02 f2 02 04 00 08 48 54 54 50 2f 31 2e 31 | .4.?HTTP/1.1 00 00 2b 2f 63 6f 6d 6d 6f 6e 2f 63 75 73 74 6f | ..+/common/custo 6d 65 72 2f 62 6f 75 6e 64 61 72 79 2f 6c 6f 67 | mer/boundary/log 69 6e 5a 69 70 63 6f 64 65 52 48 2e 64 6f 00 00 | inZipcodeRH.do.. 0d 31 39 35 2e 39 33 2e 36 30 2e 31 30 35 00 ff | .195.93.60.105.? ff 00 0f 77 77 77 2e 70 72 65 6d 69 65 72 65 2e | ?..www.premiere. 64 65 00 00 50 00 00 0c a0 01 00 a4 69 6d 61 67 | de..P...?..?imag 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 2d 78 | e/gif, image/x-x 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f 6a 70 | bitmap, image/jp 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 67 2c | eg, image/pjpeg, 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 73 | application/x-s 68 6f 63 6b 77 61 76 65 2d 66 6c 61 73 68 2c 20 | hockwave-flash, 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6d 73 77 6f | application/mswo 72 64 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f | rd, application/ 76 6e 64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 | vnd.ms-excel, ap 70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 | plication/vnd.ms 2d 70 6f 77 65 72 70 6f 69 6e 74 2c 20 2a 2f 2a | -powerpoint, */* 00 a0 03 00 0d 67 7a 69 70 2c 20 64 65 66 6c 61 | .?...gzip, defla 74 65 00 a0 04 00 02 64 65 00 00 0d 43 61 63 68 | te.?...de...Cach 65 2d 43 6f 6e 74 72 6f 6c 00 00 08 6e 6f 2d 63 | e-Control...no-c 61 63 68 65 00 a0 08 00 03 31 36 31 00 a0 07 00 | ache.?...161.?.. 21 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 2d 77 | !application/x-w 77 77 2d 66 6f 72 6d 2d 75 72 6c 65 6e 63 6f 64 | ww-form-urlencod 65 64 00 a0 09 00 43 4a 53 45 53 53 49 4f 4e 49 | ed.?..CJSESSIONI 44 3d 33 38 44 31 41 46 42 43 32 39 33 30 30 31 | D=38D1AFBC293001 46 42 33 45 44 37 44 31 41 45 35 43 32 33 38 39 | FB3ED7D1AE5C2389 37 43 2e 41 53 54 50 50 52 4d 42 3b 20 63 6f 6f | 7C.ASTPPRMB; coo 6b 69 65 63 68 65 63 6b 3d 31 00 a0 0b 00 0f 77 | kiecheck=1.?...w 77 77 2e 70 72 65 6d 69 65 72 65 2e 64 65 00 a0 | ww.premiere.de.? 0c 00 08 6e 6f 2d 63 61 63 68 65 00 a0 0d 00 3a | ...no-cache.?..: 68 74 74 70 3a 2f 2f 77 77 77 2e 70 72 65 6d 69 | http://www.premi 65 72 65 2e 64 65 2f 63 6f 6d 6d 6f 6e 2f 63 75 | ere.de/common/cu 73 74 6f 6d 65 72 2f 62 6f 75 6e 64 61 72 79 2f | stomer/boundary/ 6c 6f 67 69 6e 52 48 2e 64 6f 00 a0 0e 00 53 4d | loginRH.do.?..SM 6f 7a 69 6c 6c 61 2f 34 2e 30 20 28 63 6f 6d 70 | ozilla/4.0 (comp 61 74 69 62 6c 65 3b 20 4d 53 49 45 20 36 2e 30 | atible; MSIE 6.0 3b 20 41 4f 4c 20 39 2e 30 3b 20 57 69 6e 64 6f | ; AOL 9.0; Windo 77 73 20 4e 54 20 35 2e 31 3b 20 53 56 31 3b 20 | ws NT 5.1; SV1; 2e 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 | .NET CLR 1.1.432 32 29 00 00 03 56 69 61 00 00 6d 48 54 54 50 2f | 2)...Via..mHTTP/ 31 2e 31 20 28 56 65 6c 6f 63 69 74 79 2f 31 2e | 1.1 (Velocity/1. 31 2e 31 20 5b 75 53 63 4d 73 20 66 20 70 20 65 | 1.1 [uScMs f p e 4e 3a 74 20 63 43 4d 70 20 73 20 5d 29 2c 20 48 | N:t cCMp s ]), H 54 54 50 2f 31 2e 30 20 66 72 72 2d 61 64 30 33 | TTP/1.0 frr-ad03 5b 43 33 35 44 33 43 36 39 5d 20 28 54 72 61 66 | [C35D3C69] (Traf 66 69 63
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 11:08 --- Hmm, This seems like you are using 'application/x-www-form-urlencoded' with GET request. Can you post the full mod_jk log from the beggining of the transaction to the end for that request. There must be some errors in ajp protocol, either setting timeout too low or forbidding post requests. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 --- Additional Comments From [EMAIL PROTECTED] 2005-08-01 20:33 --- You should also attach your mod_jk configuration (workers.properties and Jk-directives from httpd.conf) as well as the connector configuration from server.xml. This way we can check your timeout settings etc. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 20:22 --- Forgive my poor English, it is not my native language. I found following bugs since 5.5.x, may be early. 5.5.9, 5.5.10 have same bugs, too. org.apache.catalina.core.ApplicationDispatcher.doInclude //HTTP named dispatcher include //HTTP path based include invoke(outerRequest, outerResponse); // bug here -- invoke(wrequest, wresponse); // crect one org.apache.catalina.core.ApplicationDispatcher.processRequest //HTTP named dispatcher forward //HTTP path based forward invoke(outerRequest, response); // bug here -- invoke(wrequest, response); // crect 1) If you have n HttpServletRequestWrapper, then Original HttpServletRequest Dispatcher's HttpServletRequestWrapper -- wrequest -- suppose to invoke this one Your HttpServletRequestWrapper #1 Your HttpServletRequestWrapper #2 ... Your HttpServletRequestWrapper #n -- outerRequest 2) If no HttpServletRequestWrapper, then Original HttpServletRequest Dispatcher's HttpServletRequestWrapper -- wrequest==outerRequest -- it works Topper Lu email: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-31 22:40 --- Ehhh, ok, I see the light now ;) Forgive me for not being friendly, it is not my native behavior. Please do not reopen the report. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 08:56 --- Created an attachment (id=15807) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15807action=view) tomcat.log Pleas, find in the attachment tomcat logs from time the problem occured -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-28 09:55 --- It seems that you are using the (deprecated) AJP12Interceptor with the AJP/1.3 version of mod_jk. Try again with the Coyote AJP/1.3 Connector (or even the AJP13Interceptor. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] New: - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 Summary: Tomcat stoped service apache request Product: Tomcat 3 Version: 3.3.2 Final Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] We have web application using: tomcat 3.3.2, appache 1.3.29, Ajp13, BAS4.5.1, Oracle. During working hours, when load was high, it happend that tomcat stopped service requests from apache. Number of threads of apache increased, number of tomcat's thread increased as well (looked like tomcat allocated threads for apache requests, but they were not processed - no application logs) In the same time, tomcat properly serviced http requests (no apache) and freely communicate with app server. Problem was solved by tomcat restart -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 --- Additional Comments From [EMAIL PROTECTED] 2005-07-27 15:48 --- Tomcat 3.3 is not being actively developed. While this might receive attention from the one or two committers still interested in it, this attention may also never arrive, or may not be timely enough for dealing with this production issue. We recommend you upgrade to Tomcat 5.5.9. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 --- Additional Comments From [EMAIL PROTECTED] 2005-07-27 16:32 --- (In reply to comment #1) Tomcat 3.3 is not being actively developed. While this might receive attention from the one or two committers still interested in it, this attention may also never arrive, or may not be timely enough for dealing with this production issue. We recommend you upgrade to Tomcat 5.5.9. Yoav is talking out his a** as usual. I won't make any difference. Tomcat 3.3 and Tomcat 5.5.9 use the identical Connectors so any problem like this in 3.3 will occur in 5.5 as well. A thread-dump of the hung Tomcat would be extremly helpful. Otherwise with the information here it isn't even possible to rule out a long GC pause. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35896] - Tomcat stoped service apache request
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35896. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35896 --- Additional Comments From [EMAIL PROTECTED] 2005-07-27 16:52 --- Bill, I won't sink down to your childish insulting level. Everything I said in my response is true. If the problem is not in the connector (as you noted, it's impossible to know from the info provided), then what I said is especially relevant. It's good advice in general to use the latest stable, most actively supported version of a product, and not just a sub-component of it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 14:02 --- Created an attachment (id=15745) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15745action=view) Removes white background color from table tags -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 14:03 --- Created an attachment (id=15746) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15746action=view) Alternates the color of the table's row's background -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 14:04 --- Created an attachment (id=15747) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15747action=view) example output after patches -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 14:06 --- Sorry about that. Attached patches and picture as requested. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 18:08 --- OK, done. Thanks for the patch submission. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 34818] - Request alternating color scheme for html manager
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=34818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=34818 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-07-21 23:42 --- URL not found, 404 when I click on it. If you're still interested and really think alternate background rows will make a big difference for this scenario. Please reopen this issue and submit your patches here in our standard diff -u format. Thanks. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-07-21 23:55 --- Can you reproduce this reliably? I can't on my little IIS/Tomcat test setup. Are you using the latest mod_jk? Does tomcat standalone work OK? I suggest using the tomcat-user mailing list for further discussion and help debugging this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 06:33 --- The problem was with the machine setup. The machines name was changed, whereas IIS had entries related to earlier machine name. Thus, the problem is resolved and nothing to do with tomcat and IIS integration. Also, Tomcat was working fine with standalone way. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 --- Additional Comments From [EMAIL PROTECTED] 2005-07-22 06:57 --- in the same vein, a session.clone() would be very useful to keep a user logged in when returning e.g. from a paypal purchase (http://www.paypal.com/cgi-bin/webscr?cmd=p/xcl/rec/ipn-manual-outside and Bug 34391). I.e. if the user returns with the same ssl-session id, the application then could change the jsessionId without the user having to re-login. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35775] New: - GET - request parameter parsing fails with german umlaute.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35775 Summary: GET - request parameter parsing fails with german umlaute. Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] GET links in form of: http://www.host.net/help/search.html?action=searchquery=+Verkn%C3%BCpfung will bring a parameter value for key query: Verkn\u20\uc3pfung An UrlDecoder should decode the encoded url parts \u20\uc3 to 'ü' on the server side. java.net.UrlDecoder does this correctly. As soon as the first parameter is requested from a CoyoteRequestFacade-CoyoteRequest-org.apache.coyote.Request, the internal Parameters instance of the Request instance changes: It's internal member paramHashStringArray is filled with the parameters that have been modified in this wrong way: %3C is interpreted to be a unicode literal: the leading '%' is removed and the trailing parts are treated like a literal for a code point and transformed (here: LATIN CAPITAL LETTER A WITH TILDE). Perhaps the org.apache.tomcat.util.buf.UDecoder is the reason? Why not taking the std. java solution? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35775] - GET - request parameter parsing fails with german umlaute.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35775 --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 14:08 --- Problem reproduced with Tomcat 5.5.9 on Linux. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35775] - GET - request parameter parsing fails with german umlaute.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35775 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Summary|allow to crate a short-lived|allow to create a short- |secondary session from a|lived secondary session from |request to prevent cross- |a request to prevent cross- |site scripting |site scripting-like attacks --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 14:21 --- cookies might not be a good answer because the adversarial script might be able to read them too in some browsers. If one is bound to a scenario where url-rewriting with redirects is the way to go, I guess a work-around is: 1) when the user clicks on the action starting the html file-download, commons-http-client gets a new session and retrieves the jsessionid 2) in the application scope, a hash-table is stored where the html file to be downloaded is stored under the jsessionid as key 3) the browser is then redirected to the new session (thus no more a referrer with the ongoing session id) - probably in 2 steps first on a landing page in the new session that then triggers the download-action with yet another redirect itself. 4) the browser retrieves the file with its temporary jsessionid and referrer 5) once the download is finished, the file is removed from the app-scope hash-table and the session invalidated I guess the almost the same would work if the adversarial script were to exploit the jsessionid's inside cookies. Anyway, being able to obtain a secondary session Id still appears attractive to me instead of such a home-made work-around. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 14:30 --- As I said, sorry, but I am not interested at all in this functionality, which would interest very few people, and yet introduce inefficient mechanisms and lots of complexity. If you have special needs, that's ok, but you're on your own. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 16:12 --- I am re-opening this because I guess there may be multiple misunderstandings and that these misunderstandings may be part of the decision to invalidate this bug. Remy: 1) As for your issue, did you notice 3rd party cookies are allowed by default in browsers ? This is IMHO unrelated to this issue. 3rd party cookies do NOT represent a security risk per se and cannot interfere with session logic. Nothing new. A page can have only one domain. a single script cannot be read cookies across domains unless the browser is broken. Content in a web page from multiple domains != cross site scripting vulnerability. 2) You seem to have a bit too much time on your hands. This comment suggests that resources play an important role in judging the validity of the request. I would suggest that the resource question is deferred until later i.e. considered when this is due after evaluation, i.e. in a cooperative fashion compatible with the structure of this project. Voting after evaluation comes to mind. 3) There are gaping holes in session security (without SSL), it's not worth trying to patch the existing model. a) If these holes are in Tomcat then they need to be fixed. Please supply bug numbers in that case. b) If you refer to the insecurity of the general architecture of session management with HTTP as it stands, then this would be even more a reason to have tomcat provide intrinsic security and give better support to struggling programmers. Tomcat is there to provide advanced frameworks that free programmers from hand coding these mechanisms. 4) As I said, sorry, but I am not interested at all in this functionality, which would interest very few people, and yet introduce inefficient mechanisms and lots of complexity. If you have special needs, that's ok, but you're on your own. a) It is regarded unprofessional in a cooperative environment such as this to let an overriding personal interest get in the way of making balanced decisions. This behavior is sometimes called corrupt although I am not saying that you are necessarily corrupt. b) It is always considered worthwhile to plug a significant security hole in exchange for a minimal, sometimes major modification. inefficient mechanisms and lots of complexity - maybe - but likewise may be not in this case. One has to think it through first. c) special needs. Ralf's needs are not special, they are quite generic. They can be condensed into the ubiquitous requirement to have a strictly limited single file download session within a major browsing session. It is a high priority business requirement to ensure that such sessions are not re-used by third parties. In a summary, it appears that there is an overwhelming number of reasons to finally start evaluating this request for enhancement. I would also suggest a less confrontational approach. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to create a short-lived secondary session from a request to prevent cross-site scripting-like attacks
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 16:33 --- (In reply to comment #6) I am re-opening this because I guess there may be multiple misunderstandings and that these misunderstandings may be part of the decision to invalidate this bug. BZ is not a discussion forum for development. I am using this post to either: a) make you go away and annoy other developers b) use the proper communication medium, aka tomcat-dev Remy: 1) As for your issue, did you notice 3rd party cookies are allowed by default in browsers ? This is IMHO unrelated to this issue. 3rd party cookies do NOT represent a security risk per se and cannot interfere with session logic. Nothing new. A page can have only one domain. a single script cannot be read cookies across domains unless the browser is broken. Content in a web page from multiple domains != cross site scripting vulnerability. I am talking about setting a session cookie for another domain, not reading cookies. 2) You seem to have a bit too much time on your hands. This comment suggests that resources play an important role in judging the validity of the request. I would suggest that the resource question is deferred until later i.e. considered when this is due after evaluation, i.e. in a cooperative fashion compatible with the structure of this project. Voting after evaluation comes to mind. Well, find another project to cooperate with, then ;) 3) There are gaping holes in session security (without SSL), it's not worth trying to patch the existing model. a) If these holes are in Tomcat then they need to be fixed. Please supply bug numbers in that case. b) If you refer to the insecurity of the general architecture of session management with HTTP as it stands, then this would be even more a reason to have tomcat provide intrinsic security and give better support to struggling programmers. Tomcat is there to provide advanced frameworks that free programmers from hand coding these mechanisms. Obviously, only SSL can ever hope to be secure. If you need security, use SSL and you have a hope of being secure, everything else is just hacks. 4) As I said, sorry, but I am not interested at all in this functionality, which would interest very few people, and yet introduce inefficient mechanisms and lots of complexity. If you have special needs, that's ok, but you're on your own. a) It is regarded unprofessional in a cooperative environment such as this to let an overriding personal interest get in the way of making balanced decisions. Again, feel free to go elsewhere :) This behavior is sometimes called corrupt although I am not saying that you are necessarily corrupt. Corrupt is fine by me, I've been called far worse. b) It is always considered worthwhile to plug a significant security hole in exchange for a minimal, sometimes major modification. inefficient mechanisms and lots of complexity - maybe - but likewise may be not in this case. One has to think it through first. This is huge and very costly. Besides, it is useless security. c) special needs. Ralf's needs are not special, they are quite generic. They can be condensed into the ubiquitous requirement to have a strictly limited single file download session within a major browsing session. It is a high priority business requirement to ensure that such sessions are not re-used by third parties. In a summary, it appears that there is an overwhelming number of reasons to finally start evaluating this request for enhancement. I would also suggest a less confrontational approach. I think the session manager, as done in Tomcat and likely all other servers, is a decent, balanced solution. If you have specific needs, you should be able to devise your own custom solution. As usual, I see a lot of willingness to shove down the throat of everyone your own little needs (and/or preferences), just to save some maintenance time on your part. I will close this without further comments as WONTFIX if reopened. If you want to talk about this, please use tomcat-dev (although I will ignore the discussion thread, and block any proposed change to the default behavior). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35775] - GET - request parameter parsing fails with german umlaute.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=35775.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35775
--- Additional Comments From [EMAIL PROTECTED] 2005-07-18 18:48 ---
This bug will not be a problem, if all url are encoded and decoded by the tomcat
encoders / decoders. But if some urls are encoded by some function that works
like the java.net.UrlEncoder with a charset argument, it will fail whenever the
charset for encoding was not ISO-8859-1, windows-1252,... (more not verified
yet) but a multi-byte charset (MBCs).
The following method may be added to a junit TestCase (import
org.apache.util.buf.* from the tomcat/server/lib/tomcat-util.jar).
/**
* Tests decoding german umlaute with apache tomcat UDecoder.p
*
*/
public void testDecodeUmlautsTomcat() {
String param = %C3%BC; // Ü
UDecoder decoder = new UDecoder();
String decoded = decoder.convert(param);
assertEquals(ü, decoded);
}
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35775] - GET - request parameter parsing fails with german umlaute.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35775. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35775 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2005-07-18 19:17 --- http://jakarta.apache.org/tomcat/faq/misc.html#tomcat5CharEncoding *** This bug has been marked as a duplicate of 34662 *** -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with request dispatcher
Hello,
i'm having a problem with calling a servlet
and dispatching to a jsp.
my example:
here is my simple html form:
html
body
form method=post action=test
Login input type=text name=login
Password input type=text name=password
input type=submit value=Envoyer
/form
/body
/html
Here's my processing servlet:
public class Test2 extends HttpServlet
{
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
System.err.println(test: doGet());
getServletContext().getRequestDispatcher(/index2.jsp).forward(request,
response);
return;
}
public void doPost(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException
{
System.err.println(test: doPost());
getServletContext().getRequestDispatcher(/index2.jsp).forward(request,
response);
return;
}
}
[/code
Here's index2.jsp code:
[code]
html
head
title/title
/head
body
test
/body
/html
The logs of the server Tomcat 5.5 on W2K and IE 6 with a single form submit:
test: doPost()
test: doGet()
When i remove doGet implementation from the servlet, there is only
test: doPost() log. So it's OK.
When the two methods are implemented, that doesn't work good.
When i remove getRequestDispatcher... line in the doPost() method, it works.
I don't understand.
it happens every time with this example.
Thanks for your help
Julien
DO NOT REPLY [Bug 35709] - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-07-13 11:09 --- You don't like me ? That's good, because I personally don't like people who, regardless of the guidelines published on the website (http://jakarta.apache.org/tomcat/bugreport.html), think it is cool to use BZ as a discussion list and force one developer into commenting their stuff, while their bug clearly belongs to a tomcat-dev discussion. As for your issue, did you notice 3rd party cookies are allowed by default in browsers ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] New: - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 Summary: allow to crate a short-lived secondary session from a request to prevent cross-site scripting Product: Tomcat 5 Version: Nightly Build Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] org.apache.catalina.connector.Request.doGetSession(boolean create) only will create a new session if there is no existing one. Goal: - This would be used in the following way to prevent a cross-site scripting attack if a user doesn't allow for cookies and thus uses URL-rewriting with the jsessionid. Problem description: Often web-apps deliver html files entered by one user to a receiving user via the HttpServletResponse object. When the receiver then views the received file, the browser still has the jsession ID in the referrer field. A script could use this to transfer that jsessionid to another server to hijack that session before expiration. Apparently the referring URL will be presented to a remote (attacking) server for example when the receiver's browser loads images asked for by the html file from that remote server. Solution idea: -- 1) obtain a secondary session without invalidating the current one to which the receiving user is logged in 2) put the html file to be downloaded into that new session redirect the file-download to another (struts-) action with that temporary session id 3) deliver the html file to the receiving user with the response of the short-lived secondary session 4) upon closing the response's outputstream, immediately invalidate that temporary session Preliminary assessment: -- === i) by the time a remote server receives the temporary jsessionid, it is normally already invalidated ii) if the html-file is already rendered by the receiver's browser before fully being downloaded, a remote attacker might see the jsessionid before it is invalidated. However, since there was no real login into that session, it will not have any privileges and contents beyond the very html file the attacker originally put into circulation -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2005-07-12 22:50 --- You seem to have a bit too much time on your hands. There are gaping holes in session security (without SSL), it's not worth trying to patch the existing model. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35709] - allow to crate a short-lived secondary session from a request to prevent cross-site scripting
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35709. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35709 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2005-07-13 07:09 --- as usual, Remy, the most friendly inhabitant of this planet... ;) You are right, I would obviously use this only together with SSL and possibly even a 2-out-of-3 rule as described in Bug 22679, comm. 12 Alternatively, if you were to think that this still is a WONTFIX, how would you then prevent cross-site scripting in presence of such gaping holes -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] New: - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 Summary: Error decoding request in Tomcat server on submit of a jsp page Product: Tomcat 5 Version: 5.5.4 Platform: Other OS/Version: Windows XP Status: NEW Severity: blocker Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] On submit of a jsp page the following error comes on the server and message in browser saying Page cannot be displayed Jul 7, 2005 5:29:04 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java :519) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:361) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.ja va:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadP ool.java:684) at java.lang.Thread.run(Thread.java:595) Jul 7, 2005 5:29:04 PM org.apache.jk.common.ChannelSocket processConnection WARNING: processCallbacks status 2 Tomcat default port is commented and call to tomcat is redirected through IIS on port 8009. the first jsp page is successfully returned but the submit of this page shows the address of the next page but does not finds it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 --- Additional Comments From [EMAIL PROTECTED] 2005-07-06 00:36 --- It looks like there is a 5.0.30 Tomcat version in the works, will this fix be included in that version as well? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-07-03 10:57 --- Fixed in the CVS by using a shutdown on the socket. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Yep, this is a problem. And, as I said, we don't have keystores, so even if it did pick up the new cert it still wouldn't work for us. jean-frederic clere wrote: OK I have added a new CA using: +++ [EMAIL PROTECTED]:~ $JAVA_HOME/bin/keytool -import -trustcacerts -file ~/CERTS/demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts +++ To get Tomcat accepting client certificates from this CA I had to restart it... Bad. -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: jean-frederic clere wrote: Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? That's the problem, Tomcat might not know the CA that signed the cert. All certificate information, including CA(s), are expressed in the SAML2 metadata file. It could be that the CA that signed the client cert was something like Verisign, but it's much more likely to be the case that it's some organization's CA, which Tomcat wouldn't know about. OK I have added a new CA using: +++ [EMAIL PROTECTED]:~ $JAVA_HOME/bin/keytool -import -trustcacerts -file ~/CERTS/demoCA/cacert.pem -keystore $JAVA_HOME/jre/lib/security/cacerts +++ To get Tomcat accepting client certificates from this CA I had to restart it... Bad. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. Have you tried to use keystoreType=PKCS12 in the connector? Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= PKCS12 doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. jean-frederic clere wrote: Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= PKCS12 doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? jean-frederic clere wrote: Chad La Joie wrote: Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. BTW: mod-ssl says: +++ In practice only levels none and require are really interesting, because level optional doesn't work with all browsers and level optional_no_ca is actually against the idea of authentication (but can be used to establish SSL test pages, etc.) +++ And keystoreType= PKCS12 doesn't help. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? - 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: Feature Request: Optional No Cert validation on SSL connector
jean-frederic clere wrote: Chad La Joie wrote: Yeah, I know what mod-ssl says, and for most cases it's probably right, however the optional_no_ca option is interesting to us because it provides exactly the functionality that we need; accepting the client cert, putting it in a standard place, and allowing our application to do the verification for us. As you said, PKCS12 wouldn't help us. The problem isn't that the Java keystore is some how flawed. It's that that's just not a viable mechanism for us. Our certificates are communicated in SAML2 metadata files. These files change periodically (when new service or identity providers come online or old ones go offline). We had discussed a process whereby we'd extract the certs from the file and create a keystore but that has and unacceptable drawback, in our opinion. With the SAML2 metadata files we can get fresh copies of those files and use them immediately in a running system. With the keystore mechanism Tomcat would need to be restarted because the keystore, or at least part of it, is cached in memory and as far as I can tell, the cache is never refreshed. Given the indeterminate frequency for metadata updates, we do not see this as a viable solution for a production level system. I am not sure I got it right... If you have clients that use client certificates you only need to get them signed by a CA that is known by Tomcat or do you want to change the server certificate Tomcat is using? That's the problem, Tomcat might not know the CA that signed the cert. All certificate information, including CA(s), are expressed in the SAML2 metadata file. It could be that the CA that signed the client cert was something like Verisign, but it's much more likely to be the case that it's some organization's CA, which Tomcat wouldn't know about. -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feature Request: Optional No Cert validation on SSL connector
Hey guys, I was wondering if there were any thoughts on this particular suggestion. I hadn't seen anything on the list. Chad La Joie wrote: Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Feature Request: Optional No Cert validation on SSL connector
su correo ha sido recepcionado. gracias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AUTO {TOML#001-926-076}Feature Request: Optional No Cert validation on SSL connector
Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. Assuring you of our best services always. Warm Regards, Customer Relations TimesofMoney.com A Times Group Company - This is an automated response. Please do not respond to this email. -
AUTO {TOML#001-926-078}Feature Request: Optional No Cert validation on SSL connector
Dear Customer, Thank you for your interest in the services offered by TimesofMoney.com.We have received your email. Our Customer Relations Officer will get in touch with you shortly. Assuring you of our best services always. Warm Regards, Customer Relations TimesofMoney.com A Times Group Company - This is an automated response. Please do not respond to this email. -
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|bugs@httpd.apache.org |tomcat- ||[EMAIL PROTECTED] Component|Other Modules |Native:JK Product|Apache httpd-2.0|Tomcat 5 Version|2.0.54 |5.0.28 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35461] - bad request http 400 using mod_jk 1.2.13. After downgrading to 1.3.33 and mod_jk 1.2.5 the problems have gone. Problems occur again after using the combination Apache Webserver 1.3.33 and mod_jk 1.2.10
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35461. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35461 [EMAIL PROTECTED] changed: What|Removed |Added Priority|P2 |P3 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Feature Request: Optional No Cert validation on SSL connector
Good Morning, I work on the Internet2 Shibboleth project and we've run in to an issue with client cert authentication in a stand alone Tomcat environment (i.e. without Apache HTTPD in front of it). Shibboleth clients use client cert auth when talking with the Shibboleth server, however, the certificate chains for the clients are not in a Java keystore. Instead they are in XML files that contain a large amount of metadata needed by both the client and the server. Our current, supported, deployment configuration is to have Apache HTTPD in front of Tomcat and to use SSLVerifyClient optional_no_ca HTTPD directive. This allows the client to send its certificate, but instead of HTTPD trying to validate the cert, it just passes the cert on to the Shibboleth server. This allows us to validate the certificate against the cert chains in the metadata files within the server code (a huge support boon for us). What we'd like to request is a similar option for the SSL connector when client cert auth is used so that we can support a stand alone Tomcat set up too. Would this be possible? -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] New: - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 Summary: RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params Product: Tomcat 5 Version: 5.0.28 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Servlet JSP API AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Tomcats implementation of RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params. Seems to modify the value of the javax.servlet.forward.request_uri request attribute incorrectly, according to servlet spec SRV.8.4.2. Here are some specifics, at least with version 5.0.28. Stepping through the Tomcat source in the debugger, it appears that the request's requestURI field gets stomped on in the forward method of the RequestDispatcher (ApplicationDispatcher.doForward()). I'm not sure Tomcat is handling a ServletRequestWrapper correctly. I gather the servlet spec says that users may wrap the request/response objects with their own implementation. Tomcat's ApplicationDispatcher gets the request from the outer request (the ServletRequestWrapper), trying to keep track of the previous wrapper and current wrapper (or request) as it loops through to get the real request. With a single wrapper, the value of previous is the same as the original outer request. Then Tomcat calls... ((ServletRequestWrapper) previous).setRequest(wrapper); which is the same as calling setRequest(wrapper) on the incoming request. Tomcat does not get and save the value of the original request URI. It calls setRequestURI(path) on the wrapper, effectively changing the request URI of the original incoming request to the path of the forward. Then Tomcat sets the javax.servlet.forward.request_uri attribute by calling getRequestURI() from the original request... but that just got modified. Implying the javax.servlet.forward.request_uri attribute is going to get the value of the path for the forward. You can test this on Tomcat by using a couple JSP to. Use a HttpServletRequestWrapper in one JSP for the forward. First create result.jsp to display the desired request attribute... %@ page language=java contentType=text/html;charset=UTF-8% html head titleRequestDispatcher Test/title /head body h1Forward Request URI/h1 javax.servlet.forward.request_uri = %= request.getAttribute(javax.servlet.forward.request_uri) % /body /html Create a JSP to forward without using a wrapper, forward.jsp... % javax.servlet.RequestDispatcher rd = request.getRequestDispatcher(result.jsp); rd.forward(request, response); % and a second forward using HttpServletRequestWrapper, wrapperforward.jsp... % HttpServletRequestWrapper wrapper = new HttpServletRequestWrapper(request); javax.servlet.RequestDispatcher rd = wrapper.getRequestDispatcher(result.jsp); rd.forward(wrapper, response); % When you hit forward.jsp, the result page displays /some-context/forward.jsp for the javax.servlet.forward.request_uri request attribute. However, hit wrapperforward.jsp and the result page displays /some-context/result.jsp. From looking at the spec, I'd expect this should be /some-context/wrapperforward.jsp. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 --- Additional Comments From [EMAIL PROTECTED] 2005-06-08 17:54 --- I'm guessing that the root cause is the same, but it should also be noted that the javax.servlet.forward.servlet_path attribute is not being set correctly under these conditions either. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 --- Additional Comments From [EMAIL PROTECTED] 2005-06-08 17:44 --- I was able to reproduce this same bug on Tomcat 5.5.9 as well. The javax.servlet.forward.request_uri attribute is definitely NOT being set correctly when forwarding with a wrapped request -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35270] - RequestDispatcher forward not handling a ServletRequestWrapper correctly when updating forward request params
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35270. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35270 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-06-09 07:54 --- This is now fixed in the CVS head, and will appear in 5.5.10. It currently seems unlikely that there will be another release on the 5.0.x line, so the 5.5.x line is all that there is. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33911] - Request for security role mapping (role-to-group/user)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33911. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33911 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|NEW --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 15:19 --- Please use tomcat-dev for communicating rather than bug reports. We started a thread on possible summer of code projects. I do not think it is a good idea to change how security is done in Tomcat 5.5.x, and that any change in any upcoming Tomcat should be done once we know a little bit more about the upcoming specification. Conclusion: this is likely not a good summer of code project, due to timing issues. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33911] - Request for security role mapping (role-to-group/user)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33911. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33911 --- Additional Comments From [EMAIL PROTECTED] 2005-06-01 07:22 --- Hi I saw this thread from google's summer of codes site. I've been using Tomcat for 5-6 years and am new to JAAS. I would like to learn more about this issue and maybe I can contribute some codes. Could anyone point me to some documentations? Thanks -Lou -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
