ActiveState Perl DBI::ODBC Unicode Error

Using Perl on Windows I’m probably out begging for problems. Using 32-bit Perl on 64-bit Windows I probably deserve it. Reality however does have some needs that go above theoretical best practices.

Recently I ran into a problem with DBI::ODBC that I newly installed with Perl 5.16 on Windows Server 2008 (64 bit). Since Perl for ISAPI only works in 32 bit mode with IIS I naturally ran the 32 bit version of Perl.

All Perl-scripts where moved from our old 32-bit Perl 5.10 Windows Server 2003. They all worked great with one major exception: DBI::ODBC. We kept getting an unexpected encoding (unicode) from all our calls done by ODBC. Fortunately for us someone else had allready run into this problem.

It turns out that as of DBI::ODBC version 1.29 there was added support for unicode that “broke” expected response if one where not using unicode. After some digging into the problem with suggestions to rebuild DBI::ODBC (that I don’t even know how to do on Windows under ActiveState Perl) or encode/decode every variable I finally found what I thought was the easiest solution.

After each connection established with DBI::ODBC driver I added the flag “odbc_old_unicode” and set it to true. This makes all the subsequent calls act as they did before unicode support was added!

$dbh = DBI->connect('DBI:ODBC:MYSOURCE','USER','PASSWORD');
$dbh->{'odbc_old_unicode'} = 1;

Now I just need to find every occurence where a connection is established with ODBC in my Perl scripts… which reminds me that I am on a Windows platform and don’t have access to the “grep” command!

Note: after some digging (since I do not want to install any third party software on the servers) I found the FINDSTR command which was quite handy!

Using PHP to check response time of HTTP-server

I must start off with admiting that my PHP skills are very limited, however being a very experienced Perl hacker this is very similar to me. Edit 2013-01-30: This is no longer true 🙂

I needed a script that checked for a normal HTTP response from another server, a status script to see if the other server(s) where behaving as they should.

The resources on-line for PHP are great and I quickly found the code needed to retrieve a remote page and read the contents. I also found some tutorials describing how to use this code. My version ended up looking like this (thanks phptoys.com for the tutorial!):

<?php
// check responsetime for a webbserver
function pingDomain($domain){
    $starttime = microtime(true);
    // supress error messages with @
    $file      = @fsockopen($domain, 80, $errno, $errstr, 10);
    $stoptime  = microtime(true);
    $status    = 0;

    if (!$file){
        $status = -1;  // Site is down
    }
    else{
        fclose($file);
        $status = ($stoptime - $starttime) * 1000;
        $status = floor($status);
    }
    return $status;
}
?>

What this code does is to measure, using the microtime function, the time difference between initiating a connection using fsockopen and when that functions has completed executing. If a connection was established the time difference is returned. If fsockopen failed to open a connection -1 is returned.

The time difference is multiplied by 1000 to get the number of milliseconds it took, floor() is then used to round down to the nearest integer value.

To call this function simply add the domain or IP you want to check the response time of:

Fireflake: <?php echo pingDomain('tech.fireflake.com'); ?> ms<br>
Example: <?php echo pingDomain('www.example.com'); ?> ms<br>
Internal IP: <?php echo pingDomain('192.168.0.2'); ?> ms<br>
Fail: <?php echo pingDomain('fail.fireflake.com'); ?> ms<br>

Sample output from the above statements are:

Fireflake: 111 ms
Example: 139 ms
Internal IP: 0 ms
Fail: -1 ms

Also, sometimes DNS servers return a “search engine” response if the domain is unknown or unreachable. To be sure you reach the server you want try calling it by IP-number instead to make sure your DNS isn’t fooling you.

EDIT:  Thx for adding the tip to use @ to supress error messages. Just use @fsockopen to supress the inevitable error message.

EDIT 2013-01-30: Fixed the old code and added some more examples.

EDIT 2013-03-07: Added clarification about unit used in $status.

Slow loading with Google Analytics

I experienced my pages slowing down when using Google Analytics togheter with my Firefox AddOn NoScript. Since I’m far from the only one using NoScript I found this not acceptable and worked out a possible work around.

The reason for the slow down is likely the timeout of the connection between my domain (where I’ve allowed scripts to run) and Googles domains (where I might or might not have allowed scripts).

Googles code look like this (where “UA-1111111-1” is your tracking ID):

<script type=”text/javascript”>
var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src='” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));
</script>
<script type=”text/javascript”>
var pageTracker = _gat._getTracker(“UA-1111111-1”);
pageTracker._initData();
pageTracker._trackPageview();
</script>

The first part of the code creates an obfuscated loading of the script located at google-analytics.com/ga.js. It picks a prefix of www if it’s a standard connection and ssl if it’s  an encrypted connection. The problem is that NoScript does not recognize this code and ends up in a deadlock of wether or not to allow the script to be run. My guess is that there is another script loaded from another domain called googlesyndication.com which fails to enter the NoScript-test and locks the loading of the page.

A possible fix that I’m still evaluating but which should do the trick is the following (code in bold added):

<script src=”http://www.google-analytics.com/ga.js” type=”text/javascript”></script>
<script type=”text/javascript”>
var pageTracker = _gat._getTracker(“UA-1111111-1”);
pageTracker._initData();
pageTracker._trackPageview();
</script>

As you can see I’ve made the obfoscated code clear text code and chosen the http://www-prefix (since I’m not using an encrypted connection for my server). Should you use encryption on your site simply switch http://www to https://ssl instead (this is what the javascript used to do). If you have a page which might be loaded encrypted or normally then you would have to include this choice earlier in a server side script for example.

After this fix Google Analytics works like a charm togheter with NoScript on any script-level setting for me.

Try this at your own risc, this is still experimental to me as well!