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.