Hi Chris,
On Thu, Dec 15, 2011 at 3:07 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Alessandro,
>
> On 12/14/11 6:02 PM, Alessandro Novarini wrote:
> > My current client has web application deployed on tomcat that acts
> > as an http proxy recording all the responses from remote web
> > services in order to work "off-line" when needed.
>
> 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, it's 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.
If with Origin server you mean the "destination", then we don't really
know what kind of servers are, they just exposes web services
>
> How are you connecting from your proxy webapp to the origin server?
They're using apache common http client.
>
> 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.
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 >>>
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
>
> > In other parts of the code
> > (org.apache.coyote.http11.Http11Processor maybe? I don't have the
> > code with me right now) I see checks on the http verb used in the
> > communication, but it only checks whether this is GET or POST.
>
> That will be only for certain operations where GET and POST are
> relevant. If you can't remember what you saw, please re-check it and
> post with more details.
In the Http11Processor I see this for example
MessageBytes methodMB = request.method();
if (methodMB.equals(Constants.GET)) {
methodMB.setString(Constants.GET);
} else if (methodMB.equals(Constants.POST)) {
methodMB.setString(Constants.POST);
}
and I guess some of the job is done by the method parseHost in the
same class, but I can't debug at the moment
> Making an HTTPS request to Tomcat is not unusual.
Yes, but I'm not making a direct https connection to tomcat, that's
the point. I already tried to enable https connection with
certificates, but it doesn't just work in that 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.
Outside tomcat it seems so straightforward, there are lot of java
proxies that work with https flawlessly.
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.
> 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.
> Nobody that I know of has bothered to write an HTTP proxy module for
> Tomcat probably because there are perfectly good solutions out there
> already that don't require Tomcat at all.
Unfortunately - for the client - I agree
Thanks for your time
Alessandro
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
