tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alessandro Novarini <anovarin...@gmail.com>
Subject Re: Tomcat as https proxy
Date Thu, 15 Dec 2011 16:37:42 GMT
Chris,

On Thu, Dec 15, 2011 at 4:15 PM, Christopher Schultz
<chris@christopherschultz.net> wrote:

> No, when I said "server" I meant "server". If you are writing a proxy,
> you really ought to understand these terms:
>
> 1. User Agent - the ultimate client -- the one making the HTTP request
>
> 2. Proxy Server - the server you are babysitting
>
> 3. Origin Server - the server that actually provides the true response

Yes, probably, but in my case I have three servers, and with Origin I
meant the one that originates the request. Sorry, lesson learnt

> Oh... you are using a SOCKS proxy? That's a different thing.

Well, yes, but I guess that when you set http.proxyHost and
https.proxyHost for the jvm, the same happens, or it doesn't?

>> They're using apache common http client.
>
> Okay. But that's not the problem, is it: the proxy and the origin
> server are communicating properly: it's the client that's getting a
> 400 Bad Request, right?

Not at all, the communication from the proxy to the https server works
with no problem

> Is this something that you have written yourself, or are you expecting
> Tomcat to handle CONNECT requests and then respond with this secure
> port, etc. Tomcat generally doesn't bind to additional ports on-the-fly.

Here you can find the specification, if you have time to give it a quick look
http://curl.haxx.se/rfc/draft-luotonen-web-proxy-tunneling-01.txt

> Does this ever work? Or, are you saying that HTTPS does not work but
> HTTP does?

What we have done at the moment is to switch the https connection to
the http one, and that works fine

> If I correctly understand what you are trying to do, my guess is that
> Tomcat itself would require significant changes to support these types
> of requests. Tomcat itself would have to act as a proxy server rather
> than delegating the request to a servlet that would do such things.
> The reason is that the request itself can't be properly mapped to a
> host/context/servlet unless Tomcat could be instructed to just ignore
> everything and pass it through to a single, deputized servlet that
> would essentially handle everything. At that point, Tomcat would be
> acting as a TCP/IP server and nothing more... you'd be wasting all the
> infrastructure that Tomcat provides.

Ok, this note has been saved for the record, thanks

> Yup, and probably none of them are running within a servlet container.

Indeed, none of the proxy servers I've seen so far work within a
servlet container.

> Why? If the application speaks HTTP and can be configured with an
> HTTP/S proxy, why not simply replace your Tomcat solution with a
> "real" HTTP proxy that will do all this out of the box? Then you won't
> have to babysit all that code anymore. :)

Yes, it's not the client application that will need to be partially
rewritten, I was referring to the proxy, they need to change it moving
from a web application to a bunch of listeners/plugins/whatever that
can be connected to the proxy implementation.

> Hmm. I wonder if other commercial-grade proxies (seriously, look into
> Squid, it might do what you want) can provide the type of logging that
> you require.

Ok, I'll give it a try, but just only as a last resort.

Thanks again
Alessandro

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message