tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Can Tomcat act as an HTTPS proxy?
Date Fri, 20 Jan 2017 21:23:54 GMT
Hash: SHA256


On 1/19/17 12:21 PM, David P. Caldwell wrote:
> 1. The backend server serves files via HTTPS. (I control this, and
> may switch it to HTTP; see below.)


> 2. The proxy server has an HTTPS connector like this (but under my 
> initial solution I wasn't thinking I should use it).
> I can connect to this HTTPS connector with my client (as long as I 
> disable the various SSL security checks, given that this is a 
> self-signed certficate).

Let's Encrypt?

> 3. The proxy server also has an HTTP connector, the one that is
> the default when using the embedded API. It changes the port number
> on it to an open ephemeral port, changes the base directory to a
> temporary directory, adds a context and configures servlets and so
> forth (it's part of a framework, so it's generalized; in the case
> I'm working on, it's adding a single servlet that basically
> forwards requests to the backend).
> 4. The purpose of all this rigamarole is mocking.

Oh. That can make a lot of my questions go away. One more before I
spend any real time droning on and on:

Is this only for unit testing, and so security, trust, etc. are all
moot points?

> I'd like to get rid of some or all of that parameterization, to 
> simplify my production code, so I decided to see whether I could 
> build an HTTPS mock of the environment.

This sounds like an excellent idea. Simpler production code is
*always* better.

> The purpose of the middle proxy server is essentially to remove
> the need to also parameterize server names and stuff. (The client
> code requests real production URLs, but because they are proxied
> through the middle tier, the middle tier can forward the requests
> to the mock server.)
> So I think what I want to do is have that middle tier's HTTP
> connector pass HTTPS requests from the client through to the
> backend HTTPS server.

This is what is confusing to me. You have only two choices for
connectors: HTTP or HTTPS. You can't have the HTTPS connector use the
HTTP connector. At least not on the same server.

You either want this:

client --- HTTP --> proxy --- HTTP --> origin

or this

client --- HTTP --> proxy --- HTTPS --> origin

or this

client --- HTTPS --> proxy --- HTTP --> origin

or this

client --- HTTPS --> proxy --- HTTPS --> origin

Pick which one you want to use. Then, on the proxy, only enable the
protocol that the client needs as a Connector. For the outgoing
connection (to the origin server), there is no Connector. There is
only the proxy-as-client, which will connect to whatever protocol is
being used on the origin server.

But... if you are just trying to "mock" the backend server... doesn't
that mean that there *is no backend server* when the mocking takes place

> For what it's worth, with some additional research, it looks like 
> what's happening is that the various mechanisms I am attempting to
> use to "proxy" (tunnel) these requests are using a CONNECT request
> to Tomcat, which is returning a 400. I think. I haven't been able
> to catch it in the act.

Tomcat doesn't yet support the CONNECT protocol. There is a patch in a
BZ issue somewhere that I haven't yet tested (this is something I'm
actually interested in making work in Tomcat). So if your client is
intending to use HTTP CONNECT then you are out of luck.

If you want to use Tomcat as a reverse-proxy, then I believe there is
a servlet for that, but I've never used it.

> However, for my situation, explaining it to you suggests a
> different solution -- since I have my Tomcat "middle" server with
> an HTTPS connector, and that is working, I am also going to
> experiment with using HTTPS to communicate with the middle, and
> then switch the back end to HTTP. I'm not sure that'll help
> (because I'm not sure how I can implement the "direct all HTTPS
> requests to this host/port" without the Java client attempting to
> establish a tunnel) but I'll explore it.

Only you can decide what make the most sense to you, but my experience
with connecting to arbitrary backend services is that connection
information isn't that tough to "parameterize"... a URL plus an
SSLSocketFactory can get the job done in most cases.

- -chris
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message