-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alessandro,
On 12/15/11 10:56 AM, Alessandro Novarini wrote: > On Thu, Dec 15, 2011 at 3:07 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: >> Is the Origin server also running Tomcat, or is this exclusively >> a problem with the proxy? > > If with Origin server you mean the "client", then yes 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 > [The client is] another tomcat on another machine, but at the > moment I'm using a browser configured to use as https proxy the > tomcat with the java proxy installed. Oh... you are using a SOCKS proxy? That's a different thing. > If with Origin server you mean the "destination", then we don't > really know what kind of servers are, they just exposes web > services Okay. I just wasn't sure if you meant that the request the proxy sends to the origin was getting a 400 Bad Request or if it was the client's request to the proxy that was getting a 400 Bad Request. If you are expecting Tomcat to act as a SOCKS proxy, then I'm not sure if that's possible or a good idea. I don't understand SOCKS well enough to give you any advise. >> How are you connecting from your proxy webapp to the origin >> server? > > 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? >> Does the request come to your proxy over HTTPS? Do you call-out >> over HTTPS or is the request to the origin server over HTTP? > > Well, it seems more complicated than that, as far as I know. > Reading how the https proxy protocol works, I get that the first > connection between source and proxy is in clear http, sending the > CONNECT verb; then, the proxy replies with a secure port that the > client uses to send the https requests. 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. > This is also the reason why you usually set the http and https > proxy with same host and port, because the "real" secure > communication is done over a port decided at communication time. > >> The client gets 400 Bad Request? Can you post the complete HTTP >> conversation for this client->proxy request/response? > > The client gets a 400 Bad Request, yes. This is what happens: > > > CLIENT -> PROXY -------------------------------------- CONNECT > home.netscape.com:443 HTTP/1.0 User-agent: Mozilla/4.0 <<< empty > line >>> I don't think that's a valid HTTP 1.0 request... the request headers will be ignored IIRC. > PROXY -> CLIENT -------------------------------------- HTTP/1.0 400 > Bad Request > >> >> That URL is trivially normalizable (and not really complete, as >> it has neither a protocol nor a path) -- Tomcat should have no >> problem with that. > > It should, I agree with you. I don't know why during the normalize > it seems the code doesn't expect something with colons and port to > me Yeah, Tomcat has no idea what to do with that request. It's trying to map home.netscape.com:443 to a host/context/servlet and the URL doesn't even start with a '/'. I'm not surprised you are getting a 400 response. Does this ever work? Or, are you saying that HTTPS does not work but HTTP does? If HTTP does work but HTTPS does not, I'm sure it's because Tomcat does not understand the semantics of accepting proxy-style-HTTPS requests in this way. >> So, are you asking how to make it work inside of Tomcat or how to >> make it work outside of Tomcat? > > I'm asking whether there's any chance to make it work in tomcat, > before claiming that we need to switch to another kind of > architecture. 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. > Outside tomcat it seems so straightforward, there are lot of java > proxies that work with https flawlessly. Yup, and probably none of them are running within a servlet container. > The problem is that for telling the client this I'd like to be > 100% sure, as this means rewrite basically at least on layer of > the application. 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. :) >> If you don't need Java for anything else (do you?), then why are >> you using Tomcat at all? There are plenty of high-performance >> proxy servers available like squid that will probably do this job >> better. > > No, we need Java because this proxy does also as a recorder and > some other stuff, and here there are only java developers. 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. - -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/ iEYEARECAAYFAk7qHTwACgkQ9CaO5/Lv0PBzAACfczABe1XXlDM0+nAs8FAtsqOe Z58An3bRbJtJkmNAVmzqaHOkcWCIJNtG =18EX -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
