These file transfers are performed using Java and Apache HTTP Components library. Security is being handled by requiring clients to pass a token, which was issued to the client upon successful authentication.
But as I mentioned in my other email looks like my assumptions about HTTPS causing significantly more stress on my server for these large file transfers were wrong. -----Original Message----- From: André Warnier [mailto:a...@ice-sa.com] Sent: Wednesday, December 08, 2010 5:58 PM To: Tomcat Users List Subject: Re: enforcing SSL only for external clients Aggarwal, Ajay wrote: > Most of the application will be over SSL for external clients. There is one > part where the clients may upload or download a huge file over HTTP which I > don't want to go through SSL. I am thinking uploading/downloading these huge > files over SSL will create lot of stress on the server. > Let me be constructively critical and provide my 2 cent : If we are talking about a standard web application using a standard html interface and standard browsers, then such an upload would be triggered by a POST from a html form with a <input type="file"> in it, right ? If the upload URL (target of the form) is not within the HTTPS protected part, then anyone could access it and post a huge file to your site, no ? That may cause more stress on your server than doing this via HTTPS ever would. Or else, how are you going to ensure that any client uploading a huge file to your server is entitled to do so ? Plus, you may need to know who is doing this, just to know what to do with the file. So you would need a form of authentication that starts under HTTPS, but is valid also when posting the form under HTTP. Not necessarily evident, and in any case not evident with any of the standard Tomcat authentication methods, as Christopher pointed out. Note that there can be ways to achieve a reasonable level of security for doing this kind of thing (reasonable being a flexible concept dependent upon your precise context). But running most of the site under HTTPS except for that upload portion seems leaky to me. Better and cheaper maybe to get a bigger server. You run the risk otherwise to spend more than the difference, trying to find out ways to do this securely, which is what HTTPS provides as a matter of fact. I would run a test, uploading the same file over HTTP and over HTTPS, and measure the system's reaction, to determine really what overhead this causes, percentage-wise, for the server. Decryption should be 99.9% CPU, and in my experience that is a facet where modern servers are rarely overloaded. With huge files, your communication bandwidth is more lilely to be the limiting factor. And if it really overloads the server, then again the solution may be with a front-end which takes care of the HTTPS part. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
