Use a keep-alive SSL connection. This amortizes the SSL handshake cost over the entire page (or more). If the keep alive is long enough, say 1-5 mins, then common ajax should be included in there as well.
The other thing to do is to ask for off screen downloads of cached css/images in the login page. Off screen in this case can be style=hidden pieces. Do the smaller ones first on the page to keep the connections down. tim -----Original Message----- From: David Leangen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 5:17 PM To: users@wicket.apache.org Subject: Re: Redirect to HTTPS? Hi, Doug. > Most of my clients do not want to have trivial resources (js, > css, images) > fetched via HTTPS. This creates an undo burden on the SSL pipe and > ultimately affects performance, user experience, and capacity planning. > While this is trivial for a 100 user site with 1 txn/sec, this will not > scale well for 1000txn/sec site. I define txn as a http req in this case > not business txn. Hmmm... well, if it's a customer demand, then I guess you have no choice. I understand that you want to lessen the burden on the server, since ssl/tls causes a lot of overhead... Maybe if I were in your shoes, I'd do the same, I don't know. But, I'm not in your shoes. ;-) To me it seems really complicated for negligible benefit to mix up http with https. In other words... > There is a difference in how items are displayed and how submits/links are > to be performed. There are cases where a HTTP page has a form that is to be > submitted via HTTPS. And furthermore, when an Page is to be displayed via > HTTPS, not all items (images,resources) are to be served via HTTPS (ex: < > i.m.g src="/path/image.gif"> on a secure page will be accessed via HTTPS). > Hopefully you agree with this. ... I guess I don't agree with this. Wouldn't it just be easier to invest a little more in hardware? Anyway, you know your needs better than I do. I'm just suggesting that you think about this once more before jumping into something that doesn't seem right (to me). Also, by mixing non-secured information with a secure transaction, I think you're creating an unnecessary vulnerability. > - All images and resource links are to be accessed via HTTP irregardless if > the page itself is to be displayed in HTTP/HTTPS > - Company info page is to be available at all times and is to be accessed > via HTTP. Sure, perfectly reasonable to have the company page in the clear. What I'm suggesting is that you don't mix http with https in the same page. In these cases, you should just be able to use ExternalLink without requiring any hacks to your code. > The behaviors in your suggested approach are this: > - I cannot have a login portlet on the home page submit the form via > HTTPS unless the Home Page is in HTTPS Yep, that's what I'm saying. ;-) You could always provide a link to a "secure" login page. > - When on any secure page, the link to Company info page will first > submit via HTTPS then redirect to HTTP (two network requests) Why? If you use ExternalLink, you can link directory to http://companypage > - When on any secure page, all resources and images will be fetched via > HTTPS Yep. I think that's the correct way. > Does this make sense to you? Have I cleared up a little? or have clouded it > further? No, it's very clear. I guess we just have different ways of thinking. Please let me know how it works out for you. I'm interested. Good luck! Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
