<< Refining the DotNetNuke Release Process | DotNetNuke 4.6 Roadmap >>

Efficiently Shifting from HTTP to HTTPS in DotNetNuke

Jul25

DotNetNuke 4.5.4 introduced native support for SSL in the DotNetNuke framework. During the testing phase and since it's release there has been some discussion (here, here and here) about the efficiency of the DotNetNuke implementation when shifting from http to https and vice versa. It has been suggested that using Javascript, like that shown below, is much more efficient when performing the redirect.

<script type="text/javascript">    if(location.protocol.toLowerCase() =='http:' &&         location.href.toLowerCase().indexOf('login') > -1 )               location.href = location.href.replace('http:','https:');    if(location.protocol.toLowerCase() =='https:' &&          location.href.toLowerCase().indexOf('login') == -1 )             location.href = location.href.replace('https:','http:');             </script>

So let's analyze the two methods to determine the best approach. We'll begin by viewing the sequence diagrams for both implementations:

In both approaches we see that there are three request/response round-trips to the server. There are primarily 2 differences that are visible in the sequence diagrams: 1) the second round trip results in a normal page return for the javascript method while a 302 redirect is performed for the DotNetNuke implementation 2) the final login page includes extra javascript in the javascript version versus not requiring javascript for the DotNetNuke implementation.

Just based on the sequence diagrams I would conclude that the DotNetNuke implementation is more efficient. In the second step, the javascript version would have to return an entire webpage in order to get the javascript to perform redirect to the HTTPS protocol, while the DotNetNuke version uses a 302 redirect which is much more efficient. The 302 redirect allows the browser to bypass all page parsing and immediately begin loading the correct page, while the javascript approach necessitates that the page get parsed, the images downloaded and some javascript get executed. Not only is the page handling slower in the javascript method, but you also have the extra overhead for the full page being transmitted from the server to the browser. Finally, because the server had to return the complete page for the javascript approach, it means that it would need to go through the entire ASP.Net page lifecycle to build up the login page, even though the browser is just going to perform a redirect once it receives the page. By using the 302 redirect method, we can detect very early in the ASP.Net pipeline that we will need a redirect and therefore can short circuit the rest of the page processing and instead just return a redirect.

Instead of just relying on the sequence diagrams let's look at the actual web-traffic for further evidence of the better approach. We are going to just look at the raw request/response cycles for the web-pages and will ignore any javascript, css or image requests since those will likely be coming from the local cache and should be exactly the same for the two approaches. The javascript method was implemented by adding the javascript to the skin and did not require creating a custom login page. The DotNetNuke method required the creation of a custom login page and setting the "secure" property on the page settings. The raw requests and responses were collected using IEWatch and the raw results were saved as xml files. I have linked to the files below, but have removed cookies and postdata headers in order to simplify the xml and to hide any potentially sensitive information.

Table 1: SSL redirect using Javascript (download the raw http log)

Duration (seconds)	Method	URL	Result	Size (bytes)
0.096	POST	http://localhost/dotnetnuke_2/default.aspx	302	46,365
0.092	GET	http://localhost/dotnetnuke_2/Home/tabid/36/ctl/Login/Default.aspx?returnurl=%2fdotnetnuke_2%2fdefault.aspx	200	23,124
0.207	GET	https://localhost/dotnetnuke_2/Home/tabid/36/ctl/Login/Default.aspx?returnurl=%2fdotnetnuke_2%2fdefault.aspx	200	23,129

Table 2: DotNetNuke SSL redirect (download the raw http log)

Duration (seconds)	Method	URL	Result	Size (bytes)
0.041	POST	http://localhost/dotnetnuke_2/Home/tabid/36/Default.aspx	302	46,520
0.009	GET	http://localhost/dotnetnuke_2/SecureLogin/tabid/54/Default.aspx?returnurl=%2fdotnetnuke_2%2fHome%2ftabid%2f36%2fDefault.aspx	302	242
0.092	GET	https://localhost/dotnetnuke_2/SecureLogin/tabid/54/Default.aspx?returnurl=%2fdotnetnuke_2%2fHome%2ftabid%2f36%2fDefault.aspx	200	24,452

The results of the actual HTTP analysis confirmed what I concluded from the sequence diagram. The Javascript method is less efficient than using the built in DotNetNuke implementation. Not only can you look at the size of the response page for the second request, but you can look at the speed of the response for the second request as well.

While DotNetNuke has not always made the best architectural choice for every feature, I think we can conclude in this case that the DotNetNuke implementation is actually very efficient. I think this issue also shows why it is important to do your own analysis when someone makes a claim about DotNetNuke. The DotNetNuke team is not perfect and we are always looking for ways to improve the platform, however, we try to be pretty diligent about testing claims to make sure we are not making the problem worse. In this case I think we did our homework pretty well and have a good implementation that handles the most common use cases for SSL in the most efficient manner that we are aware of.

d3135291-9e3f-4db2-ab16-c311c205e0ab|0|.0

Tags: dotnetnuke, ssl, javascript, iewatch
Categories: DotNetNuke
Actions: Permalink | comment

Comments (3) | RSS comment feed

Comment RSS | | Kick it! |

DotNetNuke Skinning 101 (Part 2)I have often heard it said that people have difficulty creating skins for DotNetNuke. I am alw...DotNetNuke Tips and Tricks #15: DotNetNuke Visibility Widget In late 2007, Nik Kalyani created what I think is one of the coolest new DotNetNuke features to arr...DotNetNuke OpenForce 09 Speakers Announced Yesterday, announcements went out to speakers who submitted sessions for DotNetNuke OpenForce Nor...

Comments

July 25. 2007 20:07

Wow Joe. I'm beginning to wonder where your priorities are if you are spending all that time on a wild goose chase.

I never said the Javascript method was something that I thought should be implemented in DotNetNuke, as a matter of fact I explicitly stated in one thread that I was not advocating that approach be taken from within the application. I believe it adds too much overhead for the relatively small amount of sites that will actually need that functionality.

What I did say was that the implementation in dotnetnuke was not optimal, and that doing the multiple redirects was not efficient.

Since you did take the time to try and understand it though, I would be remiss if I didn't spend a little time to point out some problems I see in your analysis.

First off, on my site I am not using a POST on the initial request.  I have the link going directly to the site using https, but lets say that all someone did was implement the javas cript in question and the initial request was a POST like your analysis shows.

You may not realize this, but in DNN 4.5.2 the Login skinobject was changed to be a command button so that postback processing could be done for the new returnurl feature.
So the redirect you are seeing after postback is in fact being caused by the server-side processing to add the returnUrl to the querystring. Again this is not the most optimal way of achieving that new feature.  It would be better to have left it as a hyperlink and on Page_Load add the returnurl to the querystring.

So the first redirect that your analysis is showing for both methods is actually the server-side code of the login click method, not a 302 redirect from the client-side.  Can someone actually create a 302 redirect using location.href? Try this. Start up you favorite monitor and hit this link: http://www.snapsis.com?ctl=login. Did you record any 302 responses from the server? No, but it is sitting on a secure channel when we asked for a normal one.  Is it magic?  No, changing location.href from the client produces a GET request that is performed without a round trip to the server.

Now, I would expect that you not try to bias any of this thorough analysis you did by starting with the assumption that you have to be right, but the results you give on performance are pretty hard to believe from a high level view. Why would you ever consider that doing two round-trip redirects to the server would be faster than one redirect?  Doesn't that strike you as odd?  Is it because you believe that the payload delivered after the postback is slowing it down?  My guess is that you did your measurements without starting from a cold benchmark, so it just appears that your second method is faster. Anyone really looking at the data you produced can easily see this since the last 200 GET request on both methods is almost exactly the same in size, yet you show it taking longer.

Nice diagrams.

John Mitchell

July 25. 2007 21:22

John - My priorities are where they should be:  making sure the community is getting the complete picture and is not just taking someone's word for it because they happen to post a lot to the forums.  You have repeatedly said that the DotNetNuke SSL implementation is innefficient and you point people to your javascript tip as a better method - which it is not.  The SSL implementation is completely independent of the login link implementation.  In fact given that the two features were implemented in different releases just highlights this fact.

The configuration on your site for the login page is not related to the SSL implementation.  Having a direct login page link is possible with or without SSL.  The only item that is different between the two SSL methods is how we redirect from HTTP to HTTPS.

The very fact that you attempt to post more misleading information here just makes my point.  If you go to the link http://www.snapsis.com?ctl=login your browser will issue an HTTP GET request on port 80 and will receive a complete page of 16342 bytes.  This page will then change the location.href which will cause the browser to issue another GET request on port 443 which will recieve a second page of 16362 bytes.  If this had used the SSL implementation from DotNetNuke then the first GET request would have resulted in in a 302 response of roughly 250 bytes.  You completely ignored the analysis of the processing that occurs to build that first HTTP page you return, which the user never fully gets to see and which is therefore just wasted bandwidth usage.  Using location.href is not magic.  Your browser must still make a request back to the server to get the new page you have requested by changing the page location.  So to answer your question no the browser is not causing a 302 redirect using your method.  It is causing a whole request/response cycle which means rebuilding the whole page on the server and resending that page a second time using HTTPS.  This is much less efficient than using a 302 redirect as indicated in my original analysis which you ignored.

Joe Brinkman

August 3. 2007 20:45