Re: Fw: Processing of multipart/form-data request failed. Socket read failed
If you have a file upload that works in Tomcat, but not through Apache and mod-jk going to Tomcat, then it could be a problem with the maximum allowed post size in Apache. Check in the httpd.conf configuration file for Apache, and see what value you have for LimitRequestBody. Se the value to 0 to ensure Apache does not impose a limit on the size of files that are uploaded. Rob P This message may contain confidential information. If you are not the intended recipient please inform the sender that you have received the message in error before deleting it. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Thank you for your co-operation. NHSmail is the secure email and directory service available for all NHS staff in England and Scotland NHSmail is approved for exchanging patient data and other sensitive information with NHSmail and GSi recipients NHSmail provides an email address for your career in the NHS and can be accessed anywhere - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat Connectors release
Hello, What is the schedule for Connectors release? Is a release scheduled when a critical mass of issues fixed or a major problem is resolved or a regular time-based release? George
[SECURITY] CVE-2014-7810: Apache Tomcat Security Manager Bypass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 CVE-2014-7810 Security Manager Bypass Severity: Moderate Vendor: The Apache Software Foundation Versions Affected: - - Apache Tomcat 8.0.0-RC1 to 8.0.15 - - Apache Tomcat 7.0.0 to 7.0.57 - - Apache Tomcat 6.0.0 to 6.0.43 Description: Malicious web applications could use expression language to bypass the protections of a Security Manager as expressions were evaluated within a privileged code section. This issue only affects installations that run web applications from untrusted sources. Mitigation: Users of affected versions should apply one of the following mitigations - - Upgrade to Apache Tomcat 8.0.17 or later (8.0.16 has the fix but was not released) - - Upgrade to Apache Tomcat 7.0.59 or later (7.0.58 has the fix but was not released) - - Upgrade to Apache Tomcat 6.0.44 or later Credit: This issue was discovered by the Apache Tomcat security team. References: [1] http://tomcat.apache.org/security-8.html [2] http://tomcat.apache.org/security-7.html [3] http://tomcat.apache.org/security-6.html -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVVKsbAAoJEBDAHFovYFnnTkYQAMos6+1kaJ+d+h0oGeiG7CDV PxcQ/AS0LdqXZuC92dXYNv+eQTB+pD0N9ePIyIMwsyEzeS2KGyOw5R8Klsro6lcq eYKH8Tv7egIzKO9dRCqhyWTytl73KPf0h6z4nnVHr/rTJ2/7pJX6x+7fjey5jcO+ G7kCQErj6bnNzgeMM/mLLVlM7YYrbA5hbQgplCdgRO5NpxaL+3raaJ19/gFZKjP3 Mqgwg/6uopkgxTFRh8Fprj6tdoPBXZ6Vxy3qJmcuOCt0yktaypqFPLTH+JM6pnme 6/Mdk4u6PhKyGPPlmvrub0priFl32tEyJNBkghHJd2QkYkZrM6t3wcOsgUawPJxZ hJrq+nJ7CJ3FUzcj9o05M4Q/TJ7seOurhPXF8YMIPn7ibrSb1Eq2Y0yZe/NGij/k dOZX5m3I62HeS1zjCIcIhKx9i6ZFTvfoe8/bF6/LPgAqfy2AB8+HBrRGVfqUh/QB w3AdDX7BxDWJKVgz9YknJG9keuR0tLV+MOI0M0LS9LHj9wAiunmq/+x03ZUX+coc btTrKnSuZq5sjmX5Xj7rilrSlq1GftGMnQyxOHiIzjCR9b59yS/BX/OkprrFXIAM Nd42B7vxWubKuOhXlyMlDt4QpnM3RsAFaD3irNc3LAQ3kpdtvsinExr3VaCvIcJ1 IETAzUe85oPF2HojrJDu =2DTj -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 6.0.44 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 6.0.44. Apache Tomcat is an open source software implementation of the Java Servlet, JavaServer Pages and Java Expression Language technologies. This release contains a number of bug fixes and improvements compared to version 6.0.43. The notable changes since 6.0.43 include: - Fix CVE-2014-0230 with a new system property org.apache.coyote.MAX_SWALLOW_SIZE that defaults to 2MB - Update to Tomcat Native Library version 1.1.33 to pick up the Windows binaries that are based on OpenSSL 1.0.1m and APR 1.5.1. - Allow to configure RemoteAddrValve and RemoteHostValve to adopt behavior depending on the connector port. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Note: This version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Downloads: http://tomcat.apache.org/download-60.cgi Migration guides from Apache Tomcat 5.5.x: http://tomcat.apache.org/migration.html - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat upgrade from 7 to latest 8
2015-05-14 14:49 GMT+03:00 Jammy Chen jamm...@gmail.com: Hello All, I am just trying upgrade tomcat 7 to latest GA 8 for my application, I am seeing quite lots of change in web dav functionality. The org.apache.naming.resources.ProxyDirContext do not exists do anybody know where I can find the alternative? in the past we got use resource to lookup something but now is not this one, can anybody know any doc? There is a new resources abstraction (and configuration) in Tomcat 8. The old one based on JNDI interfaces (org.apache,naming) is gone. http://tomcat.apache.org/migration.html What changes do you mean when you are talking about web dav? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Problem : Apache Tomcat 7.0 starts up fine using startup scripts; error when starting as Windows Service
From: Troy Robinson [mailto:troy.robin...@sasktel.com] Subject: Re: Problem : Apache Tomcat 7.0 starts up fine using startup scripts; error when starting as Windows Service I had installed 32 bit Apache Tomcat 7.0.59 ... and 64-bit Java 7. It's interesting ... that Tomcat starts up fine, using the startup scripts ... and the Application that I was installing Tomcat for ... also appears to be running fine. Tomcat itself is pure Java (other than the optional APR connector), so it doesn't care whether or not the JVM is 32- or 64-bit. However, the mode of the service launcher must match that of the installed JVM, since the launcher tries to load the JVM .dll into its own process. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Problem : Apache Tomcat 7.0 starts up fine using startup scripts; error when starting as Windows Service
Thanks Christopher, Yeah ... that might be the issue. I had installed 32 bit Apache Tomcat 7.0.59 ... and 64-bit Java 7. I will plan on installing the 64 bit Apache Tomcat 7.0.59 version now. It's interesting ... that Tomcat starts up fine, using the startup scripts ... and the Application that I was installing Tomcat for ... also appears to be running fine. Thanks for your help. On Wed, May 13, 2015 at 2:34 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Troy, On 5/13/15 1:55 PM, Troy Robinson wrote: Sorry about that. 'here' was just the Windows Services gui ... by highlighting the new Service called Apache Tomcat 7.0 Tomcat7 and clicking on Start the service. The error is a popup window titles Services with the following content. Windows could not start the Apache Tomcat 7.0 Tomcat7 on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 1. The Event Log had the following information : Event 7024, Service Control Manager The Apache Tomcat 7.0 Tomcat7 service terminated with the following service-specific error: Incorrect function. I'm no expert, but... This sounds like what might happen if you have a 64-bit OS+service runner, but you have a 32-bit JVM (or vice-versa). Can you double-check that your architectures match-up for all components? The commons-daemon service runner needs to match the architecture of your JVM. Did commons-daemon print anything to its own log files? You can check the configuration for where those log files will be by running Tomcat7w.exe - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVU7VTAAoJEBzwKT+lPKRYSzcQAK6w1LX9UCgQACPNOcZJA27E yZXXsKFD254LCM5Yxc/3cY8khzTps4YBLGkmKEvgN4wU3Saif36TiXaRWUvoF/YM ghlVFNuzbSWIUOV9rIBVWv0MToRWRSo//yCMEfVKQBxV+wXaWMeP8Cv/GKfY2V/X COO++cTkHN0RyzabaKKeua5LiFS1DnGRTv96X6HgTShuGFVj7CoerZSs5w3Afua7 9YXBSOcp510O/VXNAHeyw/aCtRwg18pf5iNHK90W6FqxbLN6L5EGyaZoSrtuEY+p +IPn9H3/ghpdi3FIqH2ymrUeTSn+lB2QpzipVUlDRxw0OoMBbRcj/C/qLmPkIL19 xM9elUGa4BvKVVIUWf8DUBhGDleF/xNFhqg9HwIWd30QrLKwSmP8dKhwIISLVuj8 4oPm4d7cV9f9lK2Y6AQ5YYmLwaD9vm4VODhd6uHyzSm4SHJ+YV5rAwXbZycOYIy0 tVjCJ8ep33F6M62s4Ai0jnd5xZ/yEdQl7K5jJWrBF6ysswB2N/Muwd2NOLWJK7hj 4OVJemrSEofCLlNdxYgTyJcKwd7+XsPFo2N9vxk4ds4ay+RZLoGGtcPcPcvRSdbf W2MPD5jeZAIIM2/WYh9mQMIYJmMygMMqVk+yLSMZnWF3hHhRjlJpmaZ/FYOKhfwv BCFhu1Rtz21EeuUFu0kE =DTex -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Troy Robinson Programmer Analyst SaskTel Phone (306) 777-5491; Mobile (306) 531-3810 Email: troy.robin...@sasktel.com Right Solution, Right Time -- *NOTICE: This confidential e-mail message is only for the intended recipients. If you are not the intended recipient, be advised that disclosing, copying, distributing, or any other use of this message, is strictly prohibited. In such case, please destroy this message and notify the sender.*
Re: Tomcat Connectors release
Am 14.05.2015 um 15:58 schrieb George Stanchev: Hello, What is the schedule for Connectors release? Is a release scheduled when a critical mass of issues fixed or a major problem is resolved or a regular time-based release? It is overdue. I'm heading for it during the next 7 days. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 JNDI Realm credential password update availability
So you're saying the change via JMX would update in-memory representation of the server.xml conf, and be using the update credentials, but if and when restarted it would use the credentials present in the actual server.xml? -John -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, May 13, 2015 1:28 PM To: Tomcat Users List Subject: Re: Tomcat 7 JNDI Realm credential password update availability -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 5/13/15 2:45 PM, Mark Thomas wrote: On 13/05/2015 19:13, John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) wrote: Hello, We have a Tomcat 7 server running on Linux that must use LDAP over SSL to connect to an AD server for user authentication. This configuration we have working. The issue is the credentials used to connect to the AD server must have the password updated every 180 days, and therefore updated in the JNDI Realm configuration. Is there a way to update the password in server.xml that would allow it to be recognized as changed without restarting the Tomcat server. Or some other configuration what ever it may be that would achieve this. The goal is to update the password and have it recognized as updated with no down time for the application running on the server. Any thoughts would be appreciated. server.xml changes require a restart. Can you update it via JMX as well? (That should work but I am going from memory rather than testing it / looking at the source). - From *my* memory, modifying things that come from server.xml via JMX often does nothing, because the component itself doesn't get re-initialized. You basically just change the in-memory representation of the configuration, but the component (Realm, in this case), just keeps doing what it was doing. A good example is the Connectors, though in that case, the Connector is just configuration that gets used to generate a Protocol+Endpoint so maybe I'm just thinking of this special case. Ultimately, JMX is the *right* way to do this, provided that the Realm notices that the configuration has changed and actually uses that configuration. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVU7PVAAoJEBzwKT+lPKRYOJwQAMrZi9Pu+MuG25bnTbgMCBtm gTAdkheI/ovuG2H2hjCAqUJo6x0B1piG71uOV7S0lTatTIdclUIeDR67mheZlLXx yY0oy4pFWSsH1UJE14LnTyqXUWQWGFTD1tAMmgGrXhMhkIVlltaFkBP9fxis33xN sjhJh8QL27jK80QL19PuVNhDLWJbAAAGhDlxHDqeCRZaxu9mC/9imWr4juTw/4vu l1xcy4Q8+G+nwpYjKlAv3ttpgMipfOKRlYSLVpxZO45yEbJmCZWJef51CSLL4Ib/ 0qxONW+aKndUJ1ZhAgc6ZSQL4N9Z+stNphD/IQhKK8I9SCdVuJrTrsdUjurpuMXZ d89uIduDKVLsIqnUyHH019M4zWa9xs26pJ/JJv9yyTZvkCfH2X5YAAO8tJE7kTm3 HTZA8hIWD09n4VZ0P0BZurmRt2aI/pTq6+aVhig0uEC0POA5MME5WWKidTVAat09 vRqKtQYgVWP0iBB7Cd2IVcpb2sE6ZpRgsF6K4Nw+brfr68uTk/FvD6kb/7JrpTYd Thkfyh102WQBVZxeTXOo952v1CKv0tAWdxx9/t1boRbCM9cNvDnsjKGzMgRkJ+0r Zx0/A19ORdC7uBn87+uW8Q9CgUIuN+NQuR89OS+nQSZdhnDU8pQgLZR1hoEuYCpO yRmNoIOIMQFnrKKPAqGC =psQ4 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 7 JNDI Realm credential password update availability
From: John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) [mailto:jbeau...@cisco.com] Subject: RE: Tomcat 7 JNDI Realm credential password update availability So you're saying the change via JMX would update in-memory representation of the server.xml conf, and be using the update credentials, but if and when restarted it would use the credentials present in the actual server.xml? Partially correct. The update via JMX would modify the in-memory fields, but the Realm might not notice the update and would continue to use older credentials and connections based on those (need to review the code). If Tomcat is restarted, it would use whatever is in server.xml at that time; updating via JMX does not rewrite the server.xml file. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SPNEGO test configuration with Manager webapp
On 29/03/2015 23:13, André Warnier wrote: David Marsh wrote: I've tested all the following public JDKs jdk-7u45-windows-i586.exe jdk-7u65-windows-i586.exe jdk-7u75-windows-i586.exe jdk-8-windows-i586.exe jdk-8u5-windows-i586.exe jdk-8u11-windows-i586.exe jdk-8u20-windows-i586.exe jdk-8u25-windows-i586.exe jdk-8u31-windows-i586.exe jdk-8u40-windows-i586.exe -- Only this one fails SPNEGO / Bad GSS Token Seems a recent fix must broken it. That is really great info. Thanks. As promised I have found some time to look into this. It appears that this fix in 8u40 onwards broke SPNEGO. https://bugs.openjdk.java.net/browse/JDK-8048194 The fix that was applied wasn't the one suggested in the bug report. I've spent some time looking at the code but I haven't found a way around this yet. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AJP config questions
(Hopefully, this isn't a duplicate post, but I sent the original a half-hour ago and I haven't seen it come back yet.) Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? Or maybe ajp://backend.example.com:8009/foo? BTW: we don't seem to be able to get the example to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? What if I don't want ROOT.war, but want to send / to a specific webapp? SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. Jeffrey Janner
Re: Tomcat 7 JNDI Realm credential password update availability
John Beaulaurier -X (jbeaulau - ADVANCED NETWORK INFORMATION INC at Cisco) a écrit : Hello, We have a Tomcat 7 server running on Linux that must use LDAP over SSL to connect to an AD server for user authentication. This configuration we have working. The issue is the credentials used to connect to the AD server must have the password updated every 180 days, and therefore updated in the JNDI Realm configuration. Is there a way to update the password in server.xml that would allow it to be recognized as changed without restarting the Tomcat server. Or some other configuration what ever it may be that would achieve this. The goal is to update the password and have it recognized as updated with no down time for the application running on the server. I use the following solution in a production system : * derive your own, custom MyRealm class from JNDIRealm. You will typically have to put it in the same package (org.apache.catalina.realm) to get access to some base methods and attributes. * overload key methods, such as authenticate and getRoles to perform your configuration tweaking before forwarding to the base methods. * tweaking typically includes checking the last modification date of a configuration file holding required info, reloading it and applying new config only on change. * use MyRealm instead of realm in server configuration. May sound a bit dirty but... works and takes less than 100 lines of code. And avoids rewriting everything from scratch. Hope this helps, Ludovic | | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT. | - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SPNEGO test configuration with Manager webapp
On 14/05/2015 21:11, Mark Thomas wrote: On 29/03/2015 23:13, André Warnier wrote: David Marsh wrote: I've tested all the following public JDKs jdk-7u45-windows-i586.exe jdk-7u65-windows-i586.exe jdk-7u75-windows-i586.exe jdk-8-windows-i586.exe jdk-8u5-windows-i586.exe jdk-8u11-windows-i586.exe jdk-8u20-windows-i586.exe jdk-8u25-windows-i586.exe jdk-8u31-windows-i586.exe jdk-8u40-windows-i586.exe -- Only this one fails SPNEGO / Bad GSS Token Seems a recent fix must broken it. That is really great info. Thanks. As promised I have found some time to look into this. It appears that this fix in 8u40 onwards broke SPNEGO. https://bugs.openjdk.java.net/browse/JDK-8048194 The fix that was applied wasn't the one suggested in the bug report. I've spent some time looking at the code but I haven't found a way around this yet. Good news (sort of). I have an *extremely* dirty hack that fixes this on my test instance by moving some of the data about in the token that the client sends. It works with 8u20 and 8u45. At the moment the hack is extremely fragile. I need to make it more robust and make it optional. I should be able to get that done tomorrow and have it included in the next Tomcat 8 release. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AJP config questions
Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? BTW: we don't seem to be able to get that to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? What if I don't want ROOT.war, but want to send / to a specific webapp? SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. Jeffrey Janner
Re: AJP config questions
Am 14.05.2015 um 23:58 schrieb Jeffrey Janner: Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. No you don't. ProxyPass and ProxyPassReverse and also any other Proxy* directive are implemented without using mod_rewrite. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? No. ProxyPass is used when mapping and transforming a request. ProxyPassReverse is used when mapping the LocatioN header *if* it is part of the response. In that case the response is a HTTP redirect and location points to the new address. Your backend will likely use its own address as it knows it. The backend (servlet enfine) does not know about ajp://backend.example.com. When using AJP, the servlet engine uses the web server protocol, host name and port to build a self-referential URL, but will use the context path that is really used on the backend. BTW: we don't seem to be able to get that to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. hard to tell, because you haven't said what does not work means, and you now also switched from a previous incomplete example using a balancer to another incomplete one without a balancer. You can test ProxyPass first, then ProxyPassReverse. ProxyPassReverse does not influence, whether your request is forwarded and how it will look like at the backend. It only changes an optional Locatoin header in the response. So if you look at your response with a client that doesn't follow redirects, you can check, whether your requests hits the backend, you get back a response and whether it looks like what you want. Note that if links embedded in your responses are wrong (e.g. point at /myapp instead of /app) then things get messy and you would need to use and configure mod_substitute or mod_sed or mod_proxy_html to scan through all of your responses and dynamically replace the links in it. You might also be interested in ProxyPassReverseCookiePath, which fixes path attributes of cookies, so again a response header only thing. What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? I don't understad this question. What if I don't want ROOT.war, but want to send / to a specific webapp? ProxyPass / ajp://localhost/myapp/ SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. I can't tell what how does that effect the options that need to be supplied in the connector means, because I don't know what result you want to get. In general ajp itself is always non-encrypted. Whether the backend sends a redirect to an https URL due to the security-constraint or not depends on whether you already talk https to the web server or not. If you already use https then ajp transports this information via ajp and the backend will not issue a redirect. If you talk http to the web server, then the security-constraint will issue a redirect. If the context path in the redirect is wrong, ProxyPassReverse can fix it. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. NP. Just keep in mind, that mod_jk and mod_proxy_ajo use the same AJP protocol. What differs is how it works to change path segments in requests, responses and headers. mod_proxy has specific directives for that, mod_jk not. Although not describing mod_proxy, the page http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html might be helpful. Where mod_jk and mod_proxy differ a lot is the URL Rewriting part, the AJP as a Solution is the same or at least very similar. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP config questions
Am 15.05.2015 um 02:11 schrieb Rainer Jung: Am 14.05.2015 um 23:58 schrieb Jeffrey Janner: Guys, it's been a long time since I did any work with AJP, but it looks like something I'll be implementing soon. I have a couple of basic questions, mostly related to ProxyPassReverse, but also one related to SSL. I know to turn on mod_proxy and mod_proxy_ajp and a simple ProxyPass where the source and dest paths match, i.e. both are /foo. The question is if they differ. The httpd docs give this example: Rewriting Proxied Path ProxyPass /apps/foo ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo http://www.example.com/foo but don't mention if you need to turn on the RewriteEngine. No you don't. ProxyPass and ProxyPassReverse and also any other Proxy* directive are implemented without using mod_rewrite. Also, the second line doesn't look correct. Shouldn't it be http://www.example.com/app/foo? No. ProxyPass is used when mapping and transforming a request. ProxyPassReverse is used when mapping the LocatioN header *if* it is part of the response. In that case the response is a HTTP redirect and location points to the new address. Your backend will likely use its own address as it knows it. The backend (servlet enfine) does not know about ajp://backend.example.com. When using AJP, the servlet engine uses the web server protocol, host name and port to build a self-referential URL, but will use the context path that is really used on the backend. I should probably add: ProxyPassReverse maps from right to left. So ProxyPassReverse /apps/foo http://www.example.com/foo takes any Location header whose value starts with http://www.example.com/foo; and then removes that value, sticks /apps/foo in front instead and adds protocol, host and port according to the local Apache VHost that forwarded the request. BTW: we don't seem to be able to get that to work. ProxyPass /myapp ajp://localhost:8009/myapp works, but ProxyPass /app ajp://localhost:8009/myapp does not work, and we've tried various iterations of ProxyPassReverse with it. hard to tell, because you haven't said what does not work means, and you now also switched from a previous incomplete example using a balancer to another incomplete one without a balancer. You can test ProxyPass first, then ProxyPassReverse. ProxyPassReverse does not influence, whether your request is forwarded and how it will look like at the backend. It only changes an optional Locatoin header in the response. So if you look at your response with a client that doesn't follow redirects, you can check, whether your requests hits the backend, you get back a response and whether it looks like what you want. Note that if links embedded in your responses are wrong (e.g. point at /myapp instead of /app) then things get messy and you would need to use and configure mod_substitute or mod_sed or mod_proxy_html to scan through all of your responses and dynamically replace the links in it. You might also be interested in ProxyPassReverseCookiePath, which fixes path attributes of cookies, so again a response header only thing. What's the best way to handle ROOT.war, assuming there are other webapps to deploy as well? I don't understad this question. What if I don't want ROOT.war, but want to send / to a specific webapp? ProxyPass / ajp://localhost/myapp/ SSL Question: Since our web.xml is configured to redirect all requests to SSL in the security-constraints area, how does that effect the options that need to be supplied in the connector? Right now, we just have the basic config as it comes in the initial conf.xml. I can't tell what how does that effect the options that need to be supplied in the connector means, because I don't know what result you want to get. In general ajp itself is always non-encrypted. Whether the backend sends a redirect to an https URL due to the security-constraint or not depends on whether you already talk https to the web server or not. If you already use https then ajp transports this information via ajp and the backend will not issue a redirect. If you talk http to the web server, then the security-constraint will issue a redirect. If the context path in the redirect is wrong, ProxyPassReverse can fix it. Sorry for being a newbie on this, but the last time I messed with Apache proxy was 4.0 and then I used JK. NP. Just keep in mind, that mod_jk and mod_proxy_ajo use the same AJP protocol. What differs is how it works to change path segments in requests, responses and headers. mod_proxy has specific directives for that, mod_jk not. Although not describing mod_proxy, the page http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html might be helpful. Where mod_jk and mod_proxy differ a lot is the URL Rewriting part, the AJP as a Solution is the same or at least very similar. Regards, Rainer - To unsubscribe, e-mail:
Tomcat upgrade from 7 to latest 8
Hello All, I am just trying upgrade tomcat 7 to latest GA 8 for my application, I am seeing quite lots of change in web dav functionality. The org.apache.naming.resources.ProxyDirContext do not exists do anybody know where I can find the alternative? in the past we got use resource to lookup something but now is not this one, can anybody know any doc? Jammy
