 |
 |
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. >