• request and response headers,
• cookies,
• server variables,
• environment variables,
• merged httpd.conf and .htaccess files,
• Ape debugging log messages with maximum verbosity.

Debugger shows verbose information not only for successful requests (status code 200), but also all others: redirects 3xx, client-side errors 4xx, server errors 5xx.

This debugger allows you to connect to a remote server and read debug information live. Only your session requests will be presented in the debugger window so other user requests will not be affected. This means you can run debugging in production environment.

Launching the debugger

To run the debugger mod_developer module should be enabled. The following line in  httpd.conf should be uncommented to ensure this:

LoadModule developer_module   modules/mod_developer.so

Then:

• run Helicon Ape Manager
• select the site or application to debug
• select Tools –> Start Ape Debugger
  

The result will be the following:

• a new browser window will open with the site or application selected for debugging; you’ll be able to browse the pages, perform AJAX-requests etc.
• the Debugger tab will be opened in Ape Manager and will show the requests log.

Functionality

The Debugger tab shows the log of all your requests to the site or application being debugged. The log includes the following info about each request: the path, status code, content-type and processing time in IIS.

Click on the line in the log and you’ll see detailed information about the request: request and response headers, cookies, server variables, environment variables, applied httpd.conf and merged .htaccess rules, corresponding error.log and rewrite.log records (if there are any for that request).

Headers:

.htaccess:

Logs:

The log with all debugging info may be opened directly in browser by clicking on the link ‘Open in browser’. Clicking ‘Clear log’ will remove all log entries.

To stop debugging click ‘Stop debugging’ or in Ape Manager choose Tools –> Stop Ape Debugger.

Security

The security of the debugging process is ensured as follows.

When debugging starts the following record is put in .htaccess:

SetEnv mod_developer secure-key-XXXXXXXXXXX

where XXXXXXXXXXX is a secret randomly-generated key for access to debugging info. Upon the first request to debugging session the browser will send this key to the server and will get a cookie with this key and the id of the debugging session. All requests to the server with this cookie are logged. The same cookie is owned by web-interface of debugger  (which is shown in Debugger tab). As a result, only authorized clients (browser and debugger) are allowed to make requests to be logged and receive them.

Upon termination of debugging (click on ‘Stop debugging’) the request to the server is sent and session id and all related log records are deleted. The cookie is reset. The previous cookie left in the browser becomes invalid, the logging stops.

Remote debugging

You can start .htaccess debugging on a server remotely. To do this you need to first put the line which sets mod_developer secure key into .htaccess file on your remote web site.

SetEnv mod_developer secure-key-XXXXXXXXXXX

where XXXXXXXXXXX is any random numbers or text. Then open browser and type a link like this:

http://www.example.com/developer/_ape_start_developer_session?ape_debug=secure-key-XXXXXXXXXXX 

and use same value for XXXXXXXXXXX as you used in .htaccess file. This will start debugger window with “Waiting for data” message. This window also sets special cookie in the browser to identify your debugging session. Now open new tab in same browser and navigate to your web site. You will be reading debug information in the debug session window as you navigate through your web site live.

To host WSGI-applications with Microsoft IIS 7+ web server there is a unique and free solution – Helicon Zoo. Helicon Zoo in general is an integration platform to run multiple technology stacks in Microsoft IIS web servers.

Installing Helicon Zoo & template WSGI application

To ease process of installing various web server products and technologies we are going to  Microsoft Web Platform Installer. At first let’s download and install Web Platform Installer from it’s official page. Then launch it:

click Options and in «Custom Feeds» box enter http://www.helicontech.com/zoo/feed/ , click «Add feed» and then «Ok»:

Then go to Zoo -> Packages and install Python Hosting Package:

The installation process may take time and will install all required products and engines to host various Python web applications on your server:

After installation is completed your server will be ready to host Python applications simply as any normal IIS web sites. This is really that easy.

Now we are going to create an application to host. There is a collection of project templates in Helicon Zoo feed which you can use as a starting point. Go to Zoo –> Templates and install Python WSGI project.

As you can see, when using WebPI to install project template additional dependencies can be also installed/upgraded. So if you where planning to create one WSGI project you can start right from installing Python WSGI project template instead of installing Python Hosting Package and all required dependencies for this single project will be installed anyway.

After download and install is completed you will be asked to configure WSGI-application. In our case we simply choose a name by which it will be available under Default Web Site:

After all the browser will navigate automatically to the start page for application. This is simple stub page with service information.

How it works?

Helicon Zoo Module is a native IIS 7+ module which acts as a bridge between web server and application on Python, Ruby, Perl, Node.js and other languages. This module uses FastCGI or HTTP protocol to transfer requests from web server to backend application and get responses to the client. This is asynchronous process that utilizes I/O Completion Port technology to provide highest performance and maximum capacity. Additionally Helicon Zoo Module manages backend applications, starts and stops them automatically based on a current service load and overall server resources. It sets appropriate environment for backend applications to run and monitors their health to provide instant and reliable service for all clients.

Configuration directives in web.config file of the IIS web site can be used to change some Helicon Zoo Module settings and configure appropriate environment for the application. Here is web.config example:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <heliconZoo>
      <application name="WSGI.project" >
        <environmentVariables>
          <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%APPL_PHYSICAL_PATH%\python_modules\Lib\site-packages;%PYTHONPATH%" /> 
          <add name="DEPLOY_FILE" value="deploy.py" />
          <add name="ERROR_LOG_DIR"  value="log" />
          <add name="WSGI_APP" value="wsgi.application" />
        </environmentVariables>
      </application>
    </heliconZoo>
    <handlers>
      <add name="WSGI.project#x86" scriptProcessor="python.2.7.wsgi"
           path="*" verb="*" modules="HeliconZoo_x86" preCondition="bitness32" resourceType="Unspecified" requireAccess="Script" />
      <add name="WSGI.project#x64" scriptProcessor="python.2.7.wsgi"
           path="*" verb="*" modules="HeliconZoo_x64" preCondition="bitness64" resourceType="Unspecified" requireAccess="Script" />
    </handlers>
  </system.webServer>
</configuration>

Here you can see two handlers declaration for 32 or 64 bit IIS processes that will call appropriate version of Helicon Zoo Module. Each handlers sets script processor to “python.2.7.wsgi” which instructs Helicon Zoo to use Python WSGI engine to run this application. Names of the handlers minus #suffix are used to identify additional settings for the application in the <heliconZoo> section. There you can define various environment variables that will be set in backend environment and are used to pass additional parameters to Helicon Zoo Module and application itself. Here are some of possible variables:

• PYTHONPATH – is a path where Python will look for it’s modules and additional files. Here we add current web site physical folder and python_modules\Lib\site-packages folder with modules.
• DEPLOY_FILE – name of the deploy script file that will be called on every application start. Usually there are instructions in this file to install required modules, do database migrations and other deployment things.
• DEPLOY_LOG – a path to the log file where to save deploy script output. If this variable is not set deploy script output will be sent to the client’s browser.
• ERROR_LOG_DIR – a folder where to store various application and error logs. 
• WATCH_FILE_CHANGES_MASK – set this variable to the file mask, like “*.py” and backend application will be restarted when any *.py file inside web site is changed. Useful in development environment. 
• WSGI_APP – a python path to the WSGI application to run. In our case this would be a wsgi.py file in the website root with an application function in it.

Getting and Installing SilverStripe

You can download SilverStripe from this page: http://www.silverstripe.com/silverstripe-web-application-framework/. After downloading please install CMS according to installation instructions provided by vendor.

Enabling SE-friendly URLs

Actually, SE-friendly feature is enabled by default. But SilverStripe does not originally support IIS and ISAPI_Rewrite. On the first page of the installation you may see this text:

Picture 1. Information messages in the installation.

If you open your web-site after SilverStripe installation, you will see the note that mod_rewrite is not enabled. Actually, SilverStripe tries to find mod_rewrite (only), and if the search is successful, SilverStripe automatically creates rules in .htaccess file, and you get CMS working with SE-friendly URLs!

Thus under IIS we need to do some hacking. Let’s just disable the check for mod_rewrite.
Please go to SilverStripe installation folder and open rewritetest.php file. Please find this code:

$testrewriting = file_get_contents($location);
if($testrewriting == 'OK') {
  return true;
}

And comment is out as follows:

//$testrewriting = file_get_contents($location);
//if($testrewriting == 'OK') {
  return true;
//}

So we just commented the check and left only return true and .htaccess configuration file required to run SEF URLs is already in place.
Done! Now you can use SilverStripe with pretty SE-friendly URLs powered by ISAPI_Rewrite.

Getting and Installing MediaWiki

You can download MW from this page: http://www.mediawiki.org/wiki/Download. After downloading please install MW according to installation instructions provided by the vendor.

Enabling SE-friendly URLs

Default MediaWiki URLs look like www.yousite.com/index.php?title=TITLE, but you can change them by using two configuration variables in LocalSettings.php:
$wgScript and $wgArticlePath.
In this article we will try to make
simple SEO-friendly urls like www.yousite.com/TITLE.

So, please open LocalSettings.php document (it is located in MediaWiki root folder) and append this code:

$wgScript = "";
$wgArticlePath = "$wgScript/$1";

Please note! The $wgScript variable must contain path to your MW folder. For example, if your MW installation is
C:\inetpub\wwwroot\mediawiki,
then you must write $wgScript = "/mediawiki", or if your MW installation is
C:\inetpub\wwwroot\, then you must write $wgScript = "".

Now please create .htaccess file in the installation folder of MediaWiki and put these rules into it:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?title=$1 [NC,L,QSA]

Done! Now you can use MediaWiki with pretty SE-friendly URLs.

Getting and Installing Drupal

You can download Drupal from official web site: http://drupal.org/. Please install Drupal according to installation instructions provided by vendor.

Please note! In the installation wizard you can see the configuration for enabling SE-friendly URLs, but with IIS you can’t use it because Drupal blocks controls as shown on this picture:

Picture 1. Configuration for SEO-friendly URLs during installation.

Please just leave it as is, it is possible to change this setting later.

Enabling SEO-friendly URLs

Please find the file %PATH_TO_DRUPAL%/sites/default/settings.php, where %PATH_TO_DRUPAL% is the root of Drupal’s installation folder. Open this document and append the code given below:

$conf[ 'clean_url' ] = 1;

Then please open .htaccess file located in the root folder of Drupal. There are many rules but only some of them are intended for ISAPI_Rewrite, others are for Apache Web Server.
Please remove all rules from .htaccess file and put these:

RewriteEngine on
# Modify the RewriteBase if you are using Drupal in a subdirectory or in a
# VirtualDocumentRoot and the rewrite rules are not working properly.
# For example if your site is at http://example.com/drupal uncomment and
# modify the following line:
# RewriteBase /drupal
#
# If your site is running in a VirtualDocumentRoot at http://example.com/,
# uncomment the following line:
# RewriteBase /

# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

Actually these are default Drupal rules for Apache mod_rewrite configuration and we just cut them from default .htaccess file.
Done! Now you can use Drupal CMS with pretty SEO-friendly URLs.

Getting and Installing WordPress

You can download WordPress from this web page: http://wordpress.org/download/.

Please don’t use versions lower than 2.6.1, because they will not work properly with ISAPI_Rewrite 3.

After downloading please install WordPress according to the installation instructions by the vendor. Note that in the installation wizard you may allow your blog to appear in search engines. This action enables indexing and will probably be important for you.

Picture 1. Enable indexing.

Enabling SE-friendly URLs

By default SE-friendly URLs are disabled. To enable this feature please go to WordPress administration panel. On the main page of administration panel please select “Settings” tab:

Picture 2. “Settings” tab.

Now please select “Permalinks” tab. On the opened page you can see some default schemes of prettifying your URLs.

Picture 3. “Permalinks” tab.

You may choose necessary scheme but notice that WordPress doesn’t use .htaccess file and ISAPI_Rewrite to process these permalinks. You will need to write your own rules.

Writing rules for .htaccess

Let’s write some simple rules for WordPress using ISAPI_Rewrite. Open “Permalinks” configuration as described above. Select “Custom Structure” radio box, and in adjacent field write /%post_id%/%postname% as shown on this picture:

Picture 4. “Custom Structure” field.

Please save changes. %post_id% and %postname% are special tag names. You can read more about tags here: http://codex.wordpress.org/Using_Permalinks. So we have configuration for URLs like http://domain.com/1/my-great-post, and now we need to write some rules in .htaccess file. Please create .htaccess file in the root folder of WordPress and write the following code into it:

RewriteBase / 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(\d+)/[^/]+/?$ index.php?p=$1 [NC,L]

These rules rewrite requests like /1/my-great-post to those like index.php?p=1, but only if no such physical file of folder exist.
Done! Now you can use your WordPress blog with pretty URLs!

Getting and Installing Mambo

You can download Mambo from this page: http://mambo-code.org/gf/project/mambo/frs/. After downloading please install Mambo according to installation instructions provided by vendor.

Enabling SE-friendly URLs

By default SE-friendly URLs are disabled. To enable this feature please go to Mambo administration panel. On the main page of administration panel please select “Global Configuration”

Picture 1. Mambo’s administration panel.

On the opened page you can see few tabs. Please find “SEO” tab and select it:

Picture 2. “SEO” tab.

Now you can see the configuration for SEO. Please select “yes” for option “Search Engine Friendly URLs”. Then apply and save your settings. Also please go to Mambo installation folder and rename htaccess.txt file to .htaccess.

Picture 3. SEO configuration

Now all URLs on your site are SE-friendly. But the navigation will not work properly. It happens because Mambo uses variable $_SERVER[ ‘REQUEST_URI’ ] which is not supported by IIS.

Patching Mambo

You will need to make a little fix in the Mambo’s source code. Please copy this code to clipboard:

if ( isset( $_SERVER[ 'HTTP_X_REWRITE_URL' ] ) ) {   $_SERVER[ 'REQUEST_URI' ] = $_SERVER['HTTP_X_REWRITE_URL' ]; }

Now you need to find index.php file in the root of Mambo installation folder. Please open this document with any editor and paste the above code at the top of index.php as shown on this picture:

Picture 4. Patched index.php

Done! Now you can use Mambo CMS with pretty SE-friendly URLs. This article describes how to use Mambo with its default rules in .htaccess file, but of course you may replace them.

Getting and Installing Joomla

You can download Joomla from official web site: http://joomla.org/download.html. After downloading please install Joomla according to installation instructions provided by vendor.

Enabling SE-friendly URLs

By default SE-friendly URLs are disabled. To enable this feature please go to the administration panel of Joomla. On the main page of administration panel please select “Global Configuration”

On the opened page you can see the group-box called “SEO Settings”. Please select “yes” for options “Search Engine Friendly URLs” and “Use Apache mod_rewrite”. Then apply and save your settings. Also please go to Joomla installation folder and rename htaccess.txt file to .htaccess.

Now all URLs on your site are SE-friendly. But there are some hurdles left. When you type different URLs in the address bar you always end up with the main page. It happens because Joomla uses variable $_SERVER[ ‘REQUEST_URI’ ] which is not supported by IIS.

Patching Joomla

You will need to add a little fix in the Joomla’s source code. Please copy this code to clipboard:

if ( isset( $_SERVER[ 'HTTP_X_REWRITE_URL' ] ) ) { $_SERVER[ 'REQUEST_URI' ] = $_SERVER['HTTP_X_REWRITE_URL' ]; }

Now you need to find index.php file in the root of Joomla installation folder. Open this document with any editor supporting Unix format (e.g. WordPad). Note: you can’t use Notepad to edit index.php because Notepad does not support saving in Unix format. Paste code above at the top of index.php as shown on this picture:

Done! Now you can use Joomla CMS with pretty SE-friendly URLs. This article describes how to use Joomla with its default rules in .htaccess file but of course you may replace them.

THIS ARTICLE IS OUTDATED

Please read following articles to find information how to run Django, Rails and other popular web engines on IIS:

• Running Django on Windows (with performance tests)
• Node.js on Windows (with performance tests)
• Ruby on Rails on Windows in production
• Deploying Java Servlet applications on Windows with IIS
• Running Railo on IIS in production

And you can find usage examples for various web engines on a usage page.

How it works

Helicon Zoo utilizes Microsoft Web Platform Installer (WebPI) to make installation of web frameworks and all required dependencies easy and smooth. At first, you need to download and install WebPI from Microsoft web site here. This is a great tool that is already packed with many ASP.NET and PHP applications and dependencies to install a whole technology stack on your server. And the greatest thing about WebPI is that it can be extended by adding custom repositories. So copy this link – http://www.helicontech.com/zoo/feed/, open WebPI options

put it into the Display additional scenarios field and click Add feed.

Now if you select Applications, Tools at the bottom of the list, you will find new applications: Blank Django Project, Blank Rails Project, Blank Perl Project, Blank Mojolicious Project

These are all empty “Hello World!” applications used to install all required dependencies which you can stuff with your code later.

So let’s choose Blank Django Project, click Add and Install.  This will create new IIS application with pre-defined configuration. After download and installation are completed you can use Launch application in browser link:

What’s inside

The core of Helicon Zoo is a native IIS 7 (or IIS Express) module that provides FastCGI support. This module differs from Microsoft FCGI module generally developed to provide PHP support for IIS. Helicon Zoo Module is built using super capacitive asynchronous  I/O Completion Port technology. It supports Pipe and TCP transports and additional level of configuration to run many different FastCGI-enabled frameworks. These includes flup tor Python, Rack for Ruby on Rails, FCGI and Plack for Perl and Mojolicious.

The core configuration of Helicon Zoo Module is located in the <heliconZooServer> section of applicationHost.config file. This section defines all FastCGI engines that will work with Zoo. Here is an example of Django FastCGI engine definition using pipe transport; zoofcgi.py is our Python worker with pipe transport support:

<engine name="python.2.7.pipe"
    fullPath="c:\python27\python.exe"
    arguments="-O %SystemDrive%\Zoo\Workers\python\zoofcgi.py"
    transport="pipe" />

How to deploy Django projects

Helicon Zoo offers simple way to deploy your Django applications on the server or test machine. First you install Blank Django Project in desired location using Web Platform Installer, then you overwrite this project content with your project files and set up deployment into this forlder. Blank Django Project installs all required dependencies on target machine and puts web.config (the only file needed for your application) in the root directory of application.

Web.config

Configuration of Zoo-powered applications is done with web.config file. Here is an example of such file to configure Django application for 32-bit.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <heliconZoo>
   <application name="django.project.x86" >
    <environmentVariables>
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%;%PYTHONPATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="settings" />
    </environmentVariables>
   </application>
  </heliconZoo>
  <handlers>
   <add name="django.project.x86"
       scriptProcessor="python.2.7.pipe"  path="*" verb="*"
       modules="HeliconZoo_x86" preCondition="bitness32"
       resourceType="Unspecified" requireAccess="Script" />
  </handlers>
 </system.webServer>
</configuration>

Several important things are defined here:

• scriptProcess="python.2.7.pipe" — a reference to FastCGI engine defined in the applicationHost.config;
• environment variable PYTHONPATH — a path where Python will check to load modules.  Here path to this IIS application is appended to allow Python to load additional modules directly from the directory of your application without installing them globally in the system.
• environment variable DJANGO_SETTINGS_MODULE — a Python path to the configuration file settings.py of your Django project, for example ‘mysite.settings’.

Static content

It is recommended to serve static content omitting Django to save processor time and increase performance. You can easily do this by putting all static files into a directory with the following web.config in it. This will disable Django module in directory:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
 <system.webServer>
  <handlers>
   <remove name="django.project.x86" />
  </handlers>
 </system.webServer>
</configuration>

Django configuration example

Let’s assume our Django project consists of three applications:

• site — a site itself with pages templates, static files, urls.py and settings.py;
• blog;
• store.

Static files are located in site/media and are available as /media/ virtual directory (i.e. MEDIA_URL='/media/').

After we install Blank Django Project in the root of web site and copy our Django application project in it we will have the following directory structure:

/media/ — is a virtual directory which is mapped to site/media and Django is disabled there using web.config file example above. In the root web.config PYTHONPATH points to the site root directory and DJANGO_SETTINGS_MODULE is set to site.settings:

 ...
 <heliconZoo>
   <application name="django.project.x86" >
    <environmentVariables>
     <add name="PYTHONPATH" value="%APPL_PHYSICAL_PATH%" />
     <add name="DJANGO_SETTINGS_MODULE" value="site.settings" />
    </environmentVariables>
   </application>
  </heliconZoo>
...

That’s all!
Sincerely, Helicon Tech team.

The steps to be accomplished are:

• create a table in the database to store the download counters for the products;
• create an .htaccess in Helicon Ape which will make records into the table upon each download with the help of mod_dbd module;
• create a simple aspx-page to show downloads statictics.

Preconditions

In the root of your site you have a downloads folder containing files for download (e.g., AudioCoder.msi, AudioDecoder.msi, AdditionalCodes.zip).
You have Helicon Ape installed on your Windows Server 2008 (IIS7).
You have SQL Server that will store the DB with downloads statistics.

Table for storing statistics

Run Microsoft SQL Server Management Studio and connect to your SQL server.

Right click on ‘Databases’, select ‘Create Database’, enter database name (for example ‘DownloadsCounter’) and click ‘OK’.

Now we’ll create the table itself:
Unfold the DownloadsCounter in Object Explorer, right click on ‘Tables’ and select ‘New Table…’. Name the table ‘Downloads’ and add 4 fields: id (int), moment (datetime), filename (nvarchar(50)) and ipaddress (nvarchar(50)) as shown on the pic below. You can find sql script to create table in attached DownloadsCounterExample.zip.

Done with the table!

mod_dbd configuration

Start Helicon Ape Manager, select your site from the tree and click on ‘downloads’ folder. Now write the following config in .htaccess on the right.

The config instructs mod_dbd to connect to DB, catches data from request (filename and client ip-address) and writes them into the DB.

# Helicon Ape version 3.0.0.59

# Connection settings
DBDriver mssql
DBDParams "Data Source=db2003\MSSQLSERVER2008;Initial Catalog=DownloadsCounter;\
           User ID=sa;Password=123123"

# Save Filename (for .msi & .zip files only)
SetEnvIfNoCase REQUEST_URI ^/downloads/(.+\.(?:msi|zip))$ FileNameENV=$1
SetEnvIfNoCase REMOTE_ADDR ^(.*)$ IpAddrENV=$1

# Sql query to save download event
DBDPrepareSQL "INSERT INTO DownloadsCounter.dbo.Downloads\
    (moment, filename, ipaddress)\
    VALUES (\
        GETDATE(),\
        '%{FileNameENV}e',\
        '%{IpAddrENV}e'\
    )\
" InsertDownload

# Execute sql query if request uri is .msi or .zip file
SetEnvIf request_uri \.(?:msi|zip)$ dbd_execute=InsertDownload

# limit access to statistics page to localhost only
<Files stat.aspx>
Order Deny,Allow
Deny from all
Allow from ::1 127.0.0.1 localhost
</Files>

Save your .htaccess and try to download something from the browser. If you now throw a glimpse at the ‘downloads’ table in SQL Server Management Studio, you’ll see the records appearing in it:

How it works?

Helicon Ape module is processing all requests coming to /downloads/ folder. If .zip or .msi file is requested, Ape memorizes the filename (FileNameENV) and client IP (IpAddrEnv), from which the file was requested, and inserts these data into the table by means of SQL query.

Statistics viewer

The archive attached to the article includes stat.aspx which does a very simple task—shows records from ‘downloads’ table.

Of course, that’s not the sort of viewer you need, as it must be capable of showing statistics by days, months, products etc. But designing a real-life solution is beyond the scope of this article, so feel free to advance stat.aspx by yourself.

Resulting archive

Below is the archive DownloadsCounterExample.zip containing all files from this article. To do some testing just unzip it into the root of your site and replace the database password from ‘123123’ to the one you have in both .htaccess and web.config.

DownloadsCounterExample.zip

Why is this option better?

As we already noticed, Google Analytics and like services are based on JavaScript working on the page. They know nothing about static content and other files loaded from the server.

Another option (yet another extreme) is server logs. They are not always accessible, not always enabled, besides, they require writing of special parsers or analyzers. Moreover, server logs do not provide live (current moment) info. Usually log file is created daily so their analysis is only possible at the beginning of the next day.

Summing up

The method explained above is a quick and effortless way to screw downloads counter to your site using Helicon Ape mod_dbd. The example is easily expendable, e.g. you can add more fields to the table to save Referer, User-Agent, etc., or develop a customizable statistics viewer.

We’ve just given you the basement, now it’s time for you to build a house.

Best regards,
Ruslan—Helicon Tech Team