> The problem with using an HTTP proxy to proxy a connection to your
> database server is that an http proxy is surely counting on the
> protocol to be http. I imagine that just about any proxy made since
> 1995 supports arbitrary port numbers, but that really sin't
> sufficient. A proxy that is expecting to read and parse http headers
> such as content-length and connection will totally fail to behave
> correctly if those headers are not available. You need, at minimum,
> what is called a SOCKS proxy.
We have 30+ clients all using HTTP proxies to connect to our database. It
works be cause as previously stated you must use SSL. That is, as soon as
you specify the target port to be 443, the proxy has to let the packets pass
through un touched otherwise SSL handshake will not work. We haven't found a
HTTP proxy that doesn't work with this technique.
What gives us the most headaches are proxies with authentication and in
particular single sign-on authentication. In a lot of cases our clients have
to set up special rules for our software, which they hate doing !
>Not to mention the fact that the connection will not persist. Even if
>you got this to work by modifying the listening port of the driver you
>would have to open and close each request.
95% of our clients have no connection problems since secure connections are
not closed down immediately because how does the proxy know when a request
is complete or not? The proxy cannot inspect secure data. However there are
some nasty proxies that simply shut down a connection after x amount of
time, even when data is constantly flowing over the connection! Because of
the 5% that we do have connection problems with, we had to implement a
reconnect algorithm and to make it truly work you need session management
added to both client and the PostgreSQL server so that you can identify and
close down dead connections easily...
So in summary, while it is possible do achieve connections via proxies, if
you can avoid going down this path then avoid it. Take it from someone who
has done it, its a lot of hassle!
Another solution: package everything up and use a message queue system. Most
of the JMS implementations have support for messaging over HTTP (with single
sign-on support) and you get asynchronous messaging as opposed to
synchronous.
Regards
Donald Fraser
