Chris, On Thu, Dec 15, 2011 at 4:15 PM, Christopher Schultz <ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
