-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alessandro,
On 12/15/11 11:37 AM, Alessandro Novarini wrote: > 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 No, the origin server is the server that produces the response. It's definitely a server, not a client. The process that originates the request is called the client :) >> 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? I think that's what you are talking about. > Not at all, the communication from the proxy to the https server > works with no problem Okay... just not when the client is making an HTTPS request because of the non-HTTPS CONNECT request? >> 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 Yeah, Tomcat isn't a good solution for this kind of thing. HTTP proxying is not the same as TCP/IP tunneling, which is what the above RFC is about. I think you're barking up the wrong tree. >> 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 But it doesn't produce the desired result :) >> 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. Honestly, I would look at this as my first option: if all goes well, you replace one component (your broken proxy) with another (a commercial-grade proxy) and you no longer have to maintain that proxy code yourself. You just need to learn how to configure and protect that new component. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7qJFQACgkQ9CaO5/Lv0PBcjQCghvFIX0WSW5HQIh6dQApNEWds QsYAoIBTebEYOqb9zoRfZhUFmCJBLGs1 =taQj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
