Another common question I get some from licensees of SSLRedirect, HttpCompressionAgent and nUrlRewriter is how to construct meaningful Regular Expressions which will match an incoming URL for the licensee's intended conditions.   Of course, it is my intention to use Regular Expressions within these products because Regular Expressions are an effective tool for testing a broad range of conditions.  However, it is not my intention to educate you on Regular Expression syntax.  I have found a number of Internet sources for such Regular Expression syntax knowledge....simply by Googling "Regular Expressions".

I did develop a Test Regular Expression web page, which allows you to key in an incoming string, followed by a Regular Expression string to see if the Regular Expression will match the incoming string.  CLICK HERE to use this Regular Expression test web page.

The Test Regular Expression web page is illustrated below:

Sanibel Logic has a number of products which utilize Regular Expressions.  One common question asked by licensees is how to encode Regular Expression strings within the web.config file.  Because the web.config conforms to rules for HTML encoding, any such string must first be HTML encoded, as provided by the .NET System.Web.HttpUtility.HtmlEncode method.  After the string is HTML encoded then we must consider Regular Expression special characters, which must be escaped and include the following special characters:

• "\" - Backslash
• "^" - Carat
• "." - Period
• "[" - Left bracket
• "$" - Dollar sign
• "(" - Left parenthesis
• ")" - Right parenthesis
• "|" - Pipe
• "*" - Asterisk
• "+" - Plus
• "?" - Question mark
• "{" - Left curly bracket

SSLRedirect uses Regular Expression values within the web.config SSLRedirect configuration section, within the urlsIn and urlsOut Xml tags.

HttpCompressionAgent also uses Regular Expression values within its web.config HttpCompression configuration section, within the mimeTypes, urls, assemblies and urlReferrers Xml tags.

To shortcut the process of browsing the Internet, so one can determine how to HTML encode and properly allow for Regular Expression special characters, I have written a basic web transaction which will transform an input Regular Expression string.   Click HERE to try the Regular Expression transformation web transaction.

Sample output from the Regular Expression Transformation web transaction is included for your benefit below...

HttpCompressionAgent continues to provide incredible compression efficiencies for HTTP data streams, providing between 70%-95% reduction in overall data stream size.  Of course one of the added features is that embedded resources (WebResource.axd HTTP requests) are also compressed.  Just listen to what third parties are saying in a recent Internet forum session...

HttpCompressionAgent also works flawlessly with the latest of ASP.NET features, such as ASP.NET 3.5 extensions, AJAX, etc...

Please don't take my word for it. CLICK HERE to read the entire forum exchange.

I am asked often what are some of the SEO techniques with respect to implementing web content which is effectively indexed by Google as well as other search engines.  I would tend to emphasize the following:

1. Use HTML h1 tags and provide meaningful content.
2. Use HTML title tag and provide meaningful content.
3. Use HTML meta tag with names="keywords" attribute and companion content attribute for providing meaningful keyword terms.
4. Use HTML meta tag with names="description" attribute and companion content attribute for providing meaningful content.
5. When using HTML img tag, be sure to provide meaningful content within alt attribute.
6. Review use of anchor tags to ensure meaningful content.
7. Use HTML noscript tag to retain meaningful and indexable content.
8. Use status code 301 for permanent redirects where applicable instead of status code 302.  Better yet, do a URL rewrite rather than a redirect.
9. Use sub-domains rather than folder names where possible and make sure the sub-domains have meaningful content.
10. When using user friendly URLs, make sure the URL content terms are meaningful and separated by dashes.
11. Use Internet standards compliant Site Maps whenever possible.

In certain senarios, SSLRedirect HTTPS:// redirected URLs will be changed back to HTTP:// URLs by the Microsoft ISA Server 2006, resulting in an endless loop between SSLRedirect and ISA Server 2006.  This is a problem with ISA Server 2006, however can be fixed with an ISA Server 2006 configuration change.

Symptom is outlined as:

• You have a computer that is running Microsoft Internet Security and Acceleration (ISA) Server 2006 or Microsoft Internet Security and Acceleration (ISA) Server 2004 in a split DNS infrastructure. 
• You have a Web server that automatically redirects HTTP requests to Secure Socket Layer (SSL) requests (in this case; SSLRedirect).
• You create a Web publishing rule for the Web server that redirects HTTP requests to HTTPS.
• You use one of the following configurations:
  • You configure the Web listener to listen for HTTP requests and also to use bridging. 
  • You configure the Web listener and the bridging for both HTTP and for SSL requests (HTTPS). 

In this scenario, when the Web server receives an HTTP request, it redirects the request to the ISA server as an SSL request (HTTPS).

For example, http://www.contoso.com is redirected to https://www.contoso.com.Then, the ISA server translates SSL requests to HTTP requests and redirects it back to the Web server. This causes an endless loop.

The resolution for the ISA Server 2006 problem is outlined in Microsoft Knowledge Base article 924373 .  In the KB article, follow the method 2 explicit mapping configuration change.

Here is an email from a licensee who configured the ISA Server 2006 fix as outlined in the above KB article:

A problem has been reported with DotNetNuke 4.8.4 which is problematic for SSLRedirect.  The problem occurs during the DNN login process.  This DNN 4.8.4 problem has been reported to the DNN support team, and they plan a timely release of 4.8.5, as documented in this discussion thread:

http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/118/threadid/235241/scope/posts/Default.aspx

The above discussion thread is rather lengthy, six web pages actually, however after reading this thread I think you will conclude to skip over DNN 4.8.4.

Probably the most frequent SSLRedirect installation problem is the fact that one's SSL Certificate is not properly installed beforehand.  I truly believe in a "process of elimination" when it comes to problem isolation, so I would suggest that the easiest thing to do to verify one's SSL Certificate installation is to first create a native HTML Hello World web page (HelloWorld.html).   Once created and one is sure that the SSL Certficate has been installed properly and the web site bindings are properly defined within IIS (port 80 for HTTP traffic and usually port 443 for HTTPS traffic), then simply try invoking the HelloWorld.html web page to ensure its usage with both HTTP and HTTPS.  Use of the simple HelloWorld.html web page will bypass SSLRedirect and any content management system, such as DotNetNuke.  If the HelloWorld.html web page works properly with both HTTP and HTTPs then you are set to try SSLRedirect with your real world web site environment.

Don't we just love Vista ?   However, on occasion you may find that you can not view the content of CHM files on Windows Vista. You can see the table of contents but the actual details are not displayed, illustrated as follows:

This can occur if the file has come from another computer, and the OS now blocks these from running. CHM is not the only file that can be affected.  I have also seen this issue with Javascript files that are used in Vista Gadgets.

Right click on the CHM file and display the file properties. 

You can click the Unblock button and it will allow the single CHM file to be trusted.

In addition, check that the path to the .CHM file doesn't have any # characters in it anywhere. Otherwise, the help viewer gets confused (# means something specific in HTML). If it does, you'll have to move the file somewhere else.

When trouble shooting WebKeepAlive problems, you may be asked to export and email the System Application Event Log.  To do so, proceed to the Windows Control Panel, then click on Administrative Tools and then click on the Event Viewer, as illustrated below with Windows Server 2003.  Highlight the Application event log, right click the mouse and then click on Save Log File As. 

Once the Save "Application" As  dialog window appears, provide a file name and .evt  file extension.  Be sure to compress the file first in ZIP form before emailing.

When one uses the WebKeepAlive Configuration program to add URLs and define the overall WebKeepAlive environment, all definitions are retained within the System Registry.  When trouble shooting problems, you may be asked to export the WebKeepAlive Registry contents.  To do so, execute the following instructions and email the saved file to Sanibel Logic support.

After bringing up a command prompt window, key in REGEDIT.

A GUI Registry Editor window will appear.  Navigate and click on the HKEY_LOCAL_MACHINE\SOFTWARE\Sanibel Logic\WebKeepAliveV5 registry key.  Right click the mouse and select Export.

Once the SaveAs dialog window appears, as illustrated below, provide a file name and .reg  file extension.  Be sure to compress the file first in ZIP form before emailing.