Anyone thinking about these things is encouraged to read the thread
"[CODE4LIB] EZProxy changes / alternatives ?" in the archives of this list.
cheers
stuart
On 06/19/2014 05:28 AM, Andrew Anderson wrote:
EZproxy already handles HTTPS connections for HTTPS enabled services today, and
on modern hardware (i.e. since circa 2005), cryptographic processing far
surpasses the speed of most network connections, so I do not accept the “it’s
too heavy” argument against it supporting the HTTPS to HTTP functionality.
Even embedded systems with 500MHz CPUs can terminate SSL VPNs at over 100Mb/s
these days.
All I am saying is that the model where you expose HTTPS to the patron and
still continue to use HTTP for the vendor is not possible with EZproxy today,
and there is no technical reason why it could not do so, but rather a policy
decision. While HTTPS to HTTP translation would not completely solve the
entire point of the original posting, it would be a step in the right direction
until the rest of the world caught up.
As an aside, the lightweight nature of EZproxy seems to be becoming its
Achilles Heel these days, as modern web development methods seem to be pushing
the boundaries of its capabilities pretty hard. The stance that EZproxy only
supports what it understands is going to be a problem when vendors adopt
HTTP/2.0, SDCH encoding, web sockets, etc., just as AJAX caused issues
previously. Most vendor platforms are Java based, and once Jetty starts
supporting these features, the performance chasm between dumbed-down proxy
connections and direct connections is going to become even more significant
than it is today.
