SSL Problems Since Using PageBlaster

Using PageBlaster v2.02.04 on DNN v4.06.02

Since installing and using PageBlaster, we have experienced a great many things improve on our site.  However, I have another gripe, and hopefully you can offer some advice as to how we can fix it.

We have SSL enabled on our site with the enforce option enabled.  This worked fine before.  Pages such as our login worked great, and when visiting other pages, the SSL would switch on and off as needed (and expected).  Once we installed PageBlaster, we noticed a new work flow issue.

If we visit a SSL-enabled page such as the login, we noticed all of the URLs are changed to use the SSL protocol (HTTPS).  This is not new, as DNN was doing that already.  Then, DNN would automatically rewrite the URL back to HTTP if the page was not set to be "secure".  Since installing and using PageBlaster, this behavior has changed.  Instead of the rewriting the URL, now the site displays an HTTP 404 error page stating that this page cannot be found.

I tried creating a rule that replaced all of the HTTPS links to HTTP, but that breaks the site the same way, but the other way around - resulting in SSL pages no longer working.

What is the fix for this?

I'm trying to figure out how to recreate this. 

When you say "we noticed all of the URLs are changed to use the SSL protocol (HTTPS)."

I'm not sure I follow since PageBlaster won't change the ouput of the page or redirect you unless you specifically create a rule to do that.

When you say that DNN automatically rewrites the Url back if the page is not secure I think you are talking about it redirecting instead of rewriting.

So are you saying that a page that has https in the url does not work?

Does it work if you call up an image like https://www.yourdomain.com/images/banner.gif ?

The very next line in my initial post suggests that DNN is doing this.  I understand the difference.  However, your next point is on target. 

When PageBlaster is enabled on the site, we can no longer rely on DNN being able to switch the URL back to HTTP from HTTPS.  This is only an issue with PageBlaster is enabled.  Something is overridden and forces DNN or IIS to instead serve out the HTTP 404 Error page.

When PageBlaster is not enabled, we see the usual behavior.  We click on a link from an HTTPS page, and then the URL is rewritten, and the page is rendered.

I'm still not able to recreate this. I'm not saying that it isn't a problem with PageBlaster, but I just don't know how to setup this scenario.
When DNN switches you back it does a redirect and I don't see how PageBlaster 2.2.4 could stop the redirect from happening.
When you are on a SSL secured page and you hover over a link, does it show the https:// url in the status bar, and then after you click on it it goes there, but does not do a redirect? If so, that would indicate that PageBlaster is caching the page as https, but PageBlaster will automatically not cache if there is a redirect. Maybe the page was cached as https when it was supposed to be secure and that was later turned off in the DNN Page settings. In that case I could see the cached page being returned. If that is what is happening then you can clear it up by clearing out the PageBlaster cache.

Can you point me to a site where this is happening? You can use the PM feature if you don't want to make it public.

This happens across the site, so I know it is not a page setting, as every page would have to have been changed.  Additionally, yes, once on a valid SSL page, all links on the page are prefixed with HTTPS.  And when one is clicked, the redirect you mention doesn't happen.  The HTTPS URL remains, and an HTTP 404 error is shown instead.  I will PM you the site.

NEVERMIND!  While writing this post, I once again went through the work-flow so that I could give you an accurate description of steps to recreate the problem.  When doing this, the problem doesn't exist anymore (all of a sudden). 

Weird!  Argh! I have issues like these that seemingly disappear.  Since I am the only person authorized to make changes on the live site (administration, files system, server side, etc.), I am clueless as to how this behavior could just disappear on us...  :(

If this problem resurfaces again, I will research it once more, and update this thread again should this problem persist.