Any experiences with Tomcat 9 session replication using overlay network to simulate broadcast/multicast?
I am researching if a packaged application built on Tomcat (not 100% sure of version but assuming 9 until I know 100% sure) using session state replication as described here http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html would work in an environment where broadcast/multicast is not enabled in the base networ but an overlay network is set up for the Tomcat instances for instance as described in this guide written by AWS https://aws.amazon.com/articles/overlay-multicast-in-amazon-virtual-private-cloud/? Any positive or negative experiences, tips, known "gotchas" etc. with this that you can share with me? Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284 Amazon Web Services EMEA SARL, Sverige filial, Kungsgatan 49, 111 22 Stockholm, Sweden, branch register of Bolagsverket, registration no. 516411-0669
Re: Fwd: Reverse proxy and SSL redirect
On 17/04/2020 18:15, rugman66 . wrote: > Made correction to ProxyPass and ProxyPassReverse. Good. Changing the context path in the reverse proxy opens up the possibility for all sorts of breakage and is generally best avoided if at all possible. > I have Apache 2.4.6 running as reverse proxy for Tomcat 7.0.96, both > running SSL, and a functioning redirect from HTTP to HTTPS for both > Apache and Tomcat. ( Need to use both these releases due to IT > availability and app requirements ) > Prior to enabling SSL on both a Json GET command made to the > application worked. Now after enabling SSL and the Apache redirect, > when the json calls are made to the application with the URL starting > with HTTP:// that should be > redirected to HTTPS:// the following errors occurs. > > 415 Unsupported media type > "message": "Unsupported Media Type in Header" Can you tell where that error message is coming from? httpd? Tomcat? The application? > When the same json GET command is issued to the same URL using > HTTPS:// it works. It looks as if communication is breaking down > between Apache and Tomcat. What URL is used with that GET? What appears in the access logs (httpd and Tomcat) for each of those? Can you also log the HTTP headers sent and received by the client for each request? > Apache I'm no httpd expert... > >ServerName http://foo.domain.com >Redirect / https://foo.domain.com/ > But the above looks to be consistent with: https://cwiki.apache.org/confluence/display/HTTPD/RedirectSSL > > SSLEngine on > SSLProxyProtocol all > SSLCertificateFile "/auto/foo/ssl_certificate/cert.cer" > SSLCertificateChainFile "/auto/some-path/ssl_certificate/chain.cer" > SSLCertificateKeyFile "/auto/some-path/ssl_certificate/some.key" > SSLCipherSuite "ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW" > ServerName "foo.domain.com" > TraceEnable Off > ProxyRequests Off > ProxyPreserveHost Off > SSLProxyEngine on > AddDefaultCharset utf-8 > AddType 'application/json; charset=UTF-8' .json > ProxyPass "/app" "https://foo.domain.com:8443/app; > ProxyPassReverse"/app" "https://foo.domain.com:8443/app; > Hmm. I'm wondering about that AddType but it looks OK. > Tomcat > > connectionTimeout="2" >redirectPort="443" >proxyName="foo.domian.com" >ProxyPort="80" Will this become unnecessary once the HTTPS redirect is working? The redirect will always happen in httpd. > port="8443" > scheme="https" > secure="true" > protocol="org.apache.coyote.http11.Http11AprProtocol" > SSLEnabled="true" > SSLCipherSuite="ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW" > SSLCertificateFile="/auto/foo/ssl_certificate/cert.cer" > SSLCertificateChainFile="/auto/some-path/ssl_certificate/chain.cer" > SSLCertificateKeyFile="/auto/some-path/ssl_certificate/some.key" > maxThreads="150" > clientAuth="false" > SSLProtocol="TLSv1.2 -SSLv2 -SSLv3 -TLSv1 -TLSv1.1" > maxHttpHeaderSize="32768" > URIEncoding="UTF-8" > /> Again, looks to be OK. > Appreciate any insight. I'd want to look at exactly what was in each request/response at each stage of this. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
