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/>.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to