the echothis blog

Often if you have a long-loading page,  you’ll want to stream the content as it arrives.  Firefox does a great job of aggressively rendering content, but other browsers like Google Chrome and IE don’t.

A typical workaround for this is to first “wake up” the browser, then periodically flush the output buffer – this has been known for awhile.  What’s less known, is that the textual content you’re sending actually matters as well (at least to Chrome and thus likely Safari).  E.g., a standard workaround is this:

// start output buffer
if (ob_get_level() == 0) ob_start();
for($i=0;$i<70;$i++)
{
    echo "printing...<br />";
    print str_pad('',4096)."\n";
 
    ob_flush();
    flush();
    usleep(30000);
}

But what’s interesting is that this slight modification breaks it on Chrome:

// start output buffer
if (ob_get_level() == 0) ob_start();
for($i=0;$i<70;$i++)
{
    echo "printing...\n";
    print str_pad('',4096)."\n";
 
    ob_flush();
    flush();
    usleep(30000);
}

Apparently Google engineers think <br>’s are important, but newline characters, not so much.

I run several websites on a leased VPS box and use WinSCP to SSH in. Suddenly a few days ago I got locked out, and got only “Connection Timeouts” when I tried to log in.

1. First I figured this was due to my Norton Internet Security firewall suddenly getting confused. But disabling it, and the Windows Firewall, had no effect.
2. Then I tried resetting my router and flushing my DNS cache, which I knew was a long shot but worth a try. Still no luck.
3. I tried SSH’ing in from another box on the internet and sure enough, got in right away (as did a friend of mine elsewhere and the VPS support people). So this told me that Comcast (my ISP) had decided that traffic shaping was in my best interest (or at least theirs), and was thus blocking port 22 traffic to this particular box. I should note that this server has no objectionable content on it (it’s actually for a few nonprofits I work with), I don’t transfer large files back and forth, or anything like that. And also, this is an outgoing connection, not an incoming one, so it’s 100% within the Comcast terms of use anyway.

This in mind, I logged into the server (via the other internet box) and set up sshd to run on a second, higher-number port by editing /etc/ssh/sshd_config:

...
Port 22
Port [HIGH_NUMBER]
...

Then I bounced the sshd service and was able to log in on the new port.

This of course begs the question of what exactly Comcast is doing snooping on my network traffic and blocking connections without warning.  If I have a spare few hours to sit on the phone with their tech support, I intend to find out.

Recently I volunteered to port a website from ColdFusion/SQL Server to PHP and MySql.  But rather than getting the database snapshot as a SQL script, which would have been easy to migrate, I was given the database in the form of a SQL Server backup, which has two parts: an LDF log fie and an MDF data file.

Now not being particularly skilled in SQL Server, I had to hunt around for what to do with this.  It turned out to be ultimately pretty easy.  Just install SQL Server 2008 via the Web Installer, reboot, and then launch the administration interface and run this SQL statement to import the backup file as a database:

RESTORE DATABASE mydb FROM disk = 'C:\\path\\to\\mydb.bak'
WITH REPLACE, MOVE 'mydb_Dat' TO 'C:\\Program Files\\Microsoft SQL Server\\MSSQL10.SQLEXPRESS\MSSQL\\DATA\\mydbdat.mdf',
MOVE 'mydb_log' TO 'C:\\Program Files\\Microsoft SQL Server\\MSSQL10.SQLEXPRESS\\MSSQL\\DATA\\mydblog.ldf'

Then choose “Script to File” to output the database to an ordinary SQL script, which then can be imported into MySQL.

There are a number of guides for this on the web, all of varying accuracy.  These are the minimal steps I followed to get it working for development on a stock WAMP server installation:

1. Enable ssl_module in the Apache module list
2. Create the self-signed certificate keys as per Section 3 of http://tud.at/programm/apache-ssl-win32-howto.php3:

   cd c:\path\to\wamp\bin\apache\Apache2.2.11\conf
    
   # Set a PEM passphrase of 4 characters or more.  You can leave the challenge password blank.
   openssl req -config openssl.cnf -new -out my-server.csr
    
   # Set the "Common Name" to localhost, accepting the rest of the defaults.
   openssl rsa -in privkey.pem -out my-server.key
    
   openssl x509 -in my-server.csr -out my-server.cert -req -signkey my-server.key -days 365

3. In your conf/extra/httpd-vhosts.conf, add this:

   ### SSL
   # see http://www.modssl.org/docs/2.8/ssl_reference.html for more info
    
   # change this from "sem" to avoid startup errors
   SSLMutex default
    
   SSLRandomSeed startup builtin
   SSLSessionCache none
    
   Listen 443
   <VirtualHost *:443>
   ErrorLog logs/ssl.log
   LogLevel info
   # You can later change "info" to "warn" if everything is OK
    
   SSLEngine On
   SSLCertificateFile conf/my-server.cert
   SSLCertificateKeyFile conf/my-server.key
    
   # copy the <Directory> information from the appropriate HTTP virtual host
   DocumentRoot "C:/path/to/docroot"
   <Directory />
       ...
   </Directory>
   </VirtualHost>

4. Restart Apache.

That should do it, then just navigate to http://localhost:443.  You’ll get browser warnings complaining that the certificate is self-signed and thus probably bogus, but it will work otherwise.

The CentOS directions are pretty good – follow them to the letter.  The directions in the installed /etc/httpd/conf.d/subversion.conf – less so.  In particular, your <Location> node should look something like this, in order to work (ignore the rest):

<Location /repos>
  DAV svn
  # path to your repo here
  SVNPath /var/www/svn/repos
 
  AuthType Basic
  AuthName "Subversion repos"
  AuthUserFile /etc/svn-auth-conf
  Require valid-user
</Location>