James, On 4/8/2020 5:41 PM, James H. H. Lampert wrote: > On 4/8/20 4:57 PM, Mark Eggers wrote: >> See >> https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxy >> for some examples. > > Yes. That's the very point in the documentation that has my head spinning: >>> For example, the following will allow only hosts in >>> yournetwork.example.com to access content via your proxy server: > >>>> <Proxy "*"> >>>> Require host yournetwork.example.com >>>> </Proxy> > > *Access* content?? I thought the Tomcat server is *serving* content. > >> So if I remember everything correctly, you could be really specific with >> the following: >> >> <Proxy "https://qux.baz.com";> >> Require ip 127.0.0.1 >> </Proxy> >> >> Place this inside the virtual host defined in the appropriate ssl.conf >> snippet. I think that you have an ssl.conf file per domain, right? >> >> Then in the non-ssl snippet, you would rewrite all the requests to go to >> HTTPS. > > That part makes sense, although I'm not entirely sure why I would want > to "be really specific" about the domain in the Proxy container, unless > it's to keep it from fighting with the other VirtualHosts. And actually, > I put the SSL and non-SSL VirtualHost blocks for the new domain in a > single .conf file. >
James, This is going to be way off topic, and may not be completely correct. While I'm pretty good with Apache Tomcat, I'm still learning about Apache HTTPD. We should probably have further discussions off the mailing list. Anyway from an overview standpoint, think of a proxy as a virtual file system. Instead of serving information from a directory subject to <Directory> constraints, Apache HTTPD is serving information from a proxy. From the browser's standpoint, the information is being served by Apache HTTPD, even though you're proxying Apache Tomcat. For example, on my mod_jk connected Apache Tomcat, the server is reported as: Server: Apache/2.2.15 (CentOS) This is what CentOS's patched Apache HTTPD 2.2 server reports, and is not indicative of the Apache Tomcat that I'm running behind mod_jk. So Apache HTTPD matches an incoming request to the most specific URL that it can, and then applies rules. This allows me to restrict HTTPD methods, do rewrites, and then passes the results off to Apache Tomcat (if configured to do so). When Apache Tomcat gets done with whatever it does (renders JSPs, creates / serves JSON, serves JS/CSS, etc.), it sends this back to Apache HTTPD. Apache HTTPD then does things like compress the output, edits / adds cookies, and edits / adds headers. Finally, the result gets sent to the browser. The browser has no idea that the response is generated via Apache Tomcat. OK, if someone notices a JSESSIONID, the user might have a clue. Other than that, no. I proxy behind Apache HTTPD for several reasons. Until recently, SAN certificates, Java, and Tomcat didn't play nicely together. That's changed. It's also easier to add some headers and cookies in Apache HTTPD than in Apache Tomcat. This is especially true for SameSite cookies, where certain browsers are broken and cannot handle SameSite=None. I have to do some ugly browser sniffing (fragile, not recommended) so that cookies generated by Apache Tomcat work inside an iframe. Now the order that all of this stuff happens is an entirely new discussion that might be better off-list, or on the Apache HTTPD mailing list. Think of Apache HTTPD as a Valve / Filter combination in the Apache Tomcat sense, if that helps. Oh, and being specific has some nice benefits. You can create different rules for different URLs before passing it off to a back end Apache Tomcat. Access control is just ONE of the things that you can do with Apache HTTPD sitting in front of Apache Tomcat. Running all of this in a cloud environment brings its own set of challenges. . . . just my two cents /mde/
signature.asc
Description: OpenPGP digital signature
