On 7/23/2016 3:44 PM, Paul Roubekas wrote: > On 7/23/2016 3:15 PM, Paul Roubekas wrote: >> On 7/23/2016 2:57 PM, Christopher Schultz wrote: >>> Paul, >>> >>> On 7/23/16 8:39 AM, Paul Roubekas wrote: >>>> http://www.myDomain.com gets me to Tomcat where my ROOT webapp is >>>> deployed. Thank you very much!!! >>>> A few things that still need correction... >>>> Not all my webpages/servlets are https, just one is https. >>> No problem. You'll need an HTTPS and HTTP listener in httpd, which it >>> seems you already have working. >>> >>>> I can navigate to any page on the site, except the https page, and >>>> the prefix stays at http://. >>> Good. >>> >>>> But once I hit the https page/servlet two things happen: 1) The >>>> prefix stays at https:// for any other page in the site, even >>>> though the other pages were severed up as http:// in the past. >>> That's generally because your pages are using relative links, which >>> preserve the protocol. Is this a problem? Or do you just want to >>> understand why it's not reverting back to HTTP when HTTPS is not needed? >> I would like to fix it. What do I need to do to stop this behavior? >>>> 2) The port number 8443 now shows in the address bar and does not >>>> go away. What still needs to be done to fix the above two issues.? >>> If the port number shows 8443 then the proxying isn't quite set up >>> correctly. Since you are using httpd, you are probably using port 443 >>> for HTTPS traffic. I'm not quite sure how TomEE does configuration, >>> but I suspect it's quite similar to Tomcat. For Tomcat, you'd have a >>> configuration containing a <Connector> which has all kinds of >>> attributes on it. Specifically, there will be one called >>> "redirectPort". By default, that value is set to "8443" because >>> Tomcat's default HTTPS port is 8443. Since you are using httpd, you'll >>> want to change redirectPort to "443". That should stick you to httpd >>> instead of having TomEE serve the requests over port 8443. >> These are the three <Connector> XML configuration elements in my >> server.xml for Tomee >> <Connector port="8080" protocol="HTTP/1.1" >> connectionTimeout="20000" >> redirectPort="8443" xpoweredBy="false" server="Apache >> TomEE" proxyName="www.myDomain.com" proxyPort="80" /> >> >> <Connector port="8443" maxHttpHeaderSize="8192" >> protocol="org.apache.coyote.http11.Http11Protocol" >> maxThreads="150" minSpareThreads="25" >> maxSpareThreads="75" enableLookups="false" >> disableUploadTimeout="true" acceptCount="100" >> SSLEnabled="true" scheme="https" secure="true" >> keyAlias="server" keystoreFile="[redacted]" >> keystorePass="[redacted]" >> clientAuth="false" sslProtocol="TLS" xpoweredBy="false" >> server="Apache TomEE" proxyName="www.myDomain.com" proxyPort="80"/> >> >> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" >> proxyName="www.myDomain.com" proxyPort="80"/> > Changing the redirectPort= on both <Connector> XML elements to 443 > causes the https page to have a "Unable to connect" error. What should I try next? >>> BTW if you aren't using TomEE for HTTPS directly, you can remove that >>> <Connector> entirely. If you are using AJP to proxy from httpd -> >>> TomEE, then you need no other connectors besides the AJP one. It will >>> make your TomEE configuration simpler, use fewer resources, and cause >>> less confusion (like what was happening above, because TomEE was >>> handling the requests, not httpd). I tested just having the AJP <Connector>. That did not work for the https page. All pages but the https page worked. On the https page I got the "Unable to connect" error page. >>> >>>> Later, after the above is fixed, I will be adding Bugzilla and >>>> phpBB to the Fedora 23 server. I am assuming phpBB and Bugzilla >>>> don't support ajp, and/or I don't need the ajp protocol. Is that >>>> correct? AJP is just for Tomcat? >>> AJP actually stands for Apache JServ Protocol, which was invented >>> solely for the purposes of proxying to Java-based application servers. >>> It's mostly outlived its usefulness, but there are some of us die-hard >>> fans out there that simply can't live without mod_jk and all the great >>> things is provides. mod_proxy has been playing catch-up with mod_jk >>> for a very long time, and they are closing-in on feature parity. But >>> not quite yet :) >>> >>>> Since the below questions are off topic I will not be hurt if they >>>> are not answered. I will go on to another internet search. The >>>> https configurations for phpBB and Bugzilla will just be... >>>> For phpBB: ProxyPass /bb http://localhost:80/bb ProxyPassReverse >>>> /bb http://localhost:80/bb >>> Are you running a separate server for phpBB? Typically, you'll just >>> use an Alias to point a particular URL space to your disk, and use >>> mod_php to run the scripts directly: >>> >>> Alias /bb /path/to/phpBB >> Let give that a try and get back with you. That does not work. Based on testing it seems the AJP <Connector> takes complete control of all http/https traffic. I have placed the Alias before the AJP directive. I have testing putting the Alias directive after the AJP <Connector>. In both cases when I try MyDomain.com/bb or MyDomain.com/tt return the Tomcat "HTTP Status 404" error page. I even tried...
# <Location /bb> # ProxyPass http://localhost/bb # </Location> But that did not work either. >>>> For Bugzilla: ProxyPass /tt http://localhost:80/tt ProxyPassReverse >>>> /tt http://localhost:80/tt >>> Same here: >>> >>> Alias /tt /path/to/bugzilla >>> >>> For Bugzilla specifically, you'll need to enable cgi-bin capabilities >>> on that directory. Read the Bugzilla configuration reference for how >>> to enable it. You'll end up with something like this: >>> >>> Alias /tt /path/to/bugzilla >>> RedirectMatch ^/tt$ /tt/index.cgi >>> <Directory "/path/to/bugzilla"> >>> Order allow,deny >>> Allow from all >>> >>> Options +ExecCGI >>> AllowOverride None >>> >>> AddHandler cgi-script .cgi >>> >>> DirectoryIndex index.cgi >>> >>> .. probably some authentication configuration, here, too .. >>> .. maybe IP- or LDAP-based restrictions, etc. .. >>> </Directory> I have not tested this yet. There does not seem to be a point when the other configuration don't work yet. >>> >> Thanks for answering this. >>> Hope that helps, >>> -chris >> Hope to return the favor some day :-) >> >> > > > -- > The people that bring you Usque <http://Usque.software/>. -- The people that bring you Usque <http://Usque.software/>.
signature.asc
Description: OpenPGP digital signature