-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David,
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.) Ok. > 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 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYgn/qAAoJEBzwKT+lPKRYx60P/ikPqpzWx2zHui7UKt+VOS/8 eeape8b+Jngamkp7f4/3avaia3AI48Vbrk2Y5EVGzgVzz6YDgSh/Q4eI+h9FwWGr ZpqWcN8s/WOyJWCrfxQyKkZMbZaDPmC5a5XvUbgJ6GA2v2vcJ0iGhYqEoaTf3oKw CvdWbuT8NHltccFymJCvRXLXCZTBSwBFXQFPC2PyGXzPuxhUzwapDqjWYoORGN/N X50lRTp5byzchLkk1wWJPNX+t8zNXWi9Xt+uK20yTJgpv+yJ54+x4xqzZvpVtta1 kEV7GsPnv3PYxFmMvA9y3B1SQ0aJopY24eiURVOlSaZwJ+at6wyBS9CwzPAadHte RTkdo2OJUO3wvw2UpGnikp+2ksiGAWGY+8VBTOWWmBB4yRUsMkvDM+5GTggXhcCf N1qD4l1ZqkAuqkUM2gmYQgPyVubvkVR0L6ovtQ1eXsPJ5C5DOnVyMK196Qp/EP7Y VTUYw4jZKGExojUg5Wsxh2lx2njUr5qIMwaNdfFTjfgL+UvwkiWUJrn6oOo/uC+H TjPAfDxGBXlNXG2ijHi4uM2qpzQQTyJ8lo2AClbfE2J+3Gh+Vxr0ujfezniP6RHW 4qpK+p29kbjRgN4zNFZGEDnqyzeDj9aiaE6VmuuqaHJM77hh5/ybO3n/sG7Fy7Gx HV+abq9HzY209oidPc0r =3YBI -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
