# Allow Facebook scripts and objects to be included only
# from Facebook pages
Site .facebook.com .fbcdn.net .facebook.net
Accept from .facebook.com .fbcdn.net .facebook.net
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

This tells NoScript to allow Facebook scripts (you know, to visit facebook.com), but to stop them from being included in other sites. I guess with NoScript’s surrogate scripts one might even be able to replace Facebook’s Like-widget with one that just shows the old-fashioned (and harmless)  share-button. Now wouldn’t that be fun?

Well, chances are that your disgruntled visitor was using a browser you didn’t test on, like Chrome on Mac for example? Because there is a small issue you have to take into account when “doing https”; both Chrome and Safari (but not Firefox) on Mac use OS X’s keychain, which does not have some of the intermediate certificates needed to establish the trust relationship between your signed certificate and the certificate authority’s root certificate.

As you can’t expect Apple to add intermediate certificates to their keychain by default (which Firefox does a pretty good job though) and you can’t ask all your OS X users to add the intermediate certificate by hand either,  you’ll have to solve this yourself. A good thing Apache can help you in that department with it’s SSLCertificateChainFile directive, which

sets the optional all-in-one file where you can assemble the certificates of Certification Authorities (CA) which form the certificate chain of the server certificate. This starts with the issuing CA certificate of the server certificate and can range up to the root CA certificate.

If there’s only one intermediate certificate missing between your’s and the CA’s, you can export it in good old Firefox (as a pem-file), place it in the same directory as the actual certificate and use SSLCertificateChainFile to tell Apache where to find it and that should solve the nasty errors those Twittering Mac-heads get.

From scratch to a deployed webapp in 7 steps:

1. Download & install the Google App Engine SDK
2. Download this GAE project template for PHP and unzip it in the root of the SDK directory as  projects/phptemplate/
3. Put your PHP-files in projects/phptemplate/war/ (you probably want to overwrite index.php and remove phpinfo.php)
4. Test you application locally with dev_appserver as described here
5. Login on https://appengine.google.com/ and register a new application
6. Put the app id from (5) in projects/phptemplate/war/WEB-INF/appengine-web.xml, between the <application>-tage
7. Upload your application as described here: appcfg –enable_jar_splitting update <path-to-war> (–enable_jar_splitting is needed as the WEB-INF/lib/resin.jar is rather big)

And there you have it, your very own PHP-app on GAE! Check out the Quercus info on  on how you can access Java components from within you PHP-code, it might come in very handy to use GAE’s Java API’s for the datastore, queues and all those other goodies!

(Disclaimer: while this here template seems to work, I can’t make any promises or provide any kind of warranty.  As soon as you download it, you assume all responsibilities for any problems you might cause to the Internet, GAE or the Ozone-layer.)

1. don’t lose your smartphone.
2. if you lose your smartphone, make sure you have something in place to locate it
3. if you lose your smartphone and you can’t locate it, make sure you can wipe it remotely

There are multiple solutions to locate & wipe smartphones (including HTC’s Sense online offering), but for my Sense-less HTC Magic I installed “Lookout“. Lookout is a free application that provides device location, contacts backup & restore and apparently also malware protection. If you’re willing to pay $3/month, you also get remote wipe, remote lock and backup/ restore of pictures and call log. If you lose your Android-phone, you just log in to the Lookout-website to locate and optionally lock or wipe your handset.

I’m happy using the free version for now; I activated Android’s pattern lock-screen to avoid anyone from accessing my handset and deactivating Lookout. Remote wipe is great, but I guess I can activate my Lookout Premium account if ever I need that feature?

Step 2: Upgrade
Your brand new Magic turns out to be that very first Android-phone Proximus started sellinng in May 2009, with Android 1.5, but without HTC Sense and tethering. Not really the smartphone you’d settle for, so you start looking around xda-developers for an upgrade path. You install flashrec, flash a new recovery image and in recovery flash MyHero 2.0.5 and after 1 month without it, you can finally boot into that beautiful HTC Sense UI again.

Step 3: Brick
HTC Sense, great, but still Android 1.5 and no tethering, seriously? No can do Sir, so you head back to xda-developers to figure out your next step. Late at night, after browsing millions of forum posts about perfected SPL’s, goldcards and recovery images, you find a thread with links to official HTC RUU’s. Easy-peasy and you download one of those boot your Windows PC and start flashing. HBOOT updates, radio updates, … all goes well and you doze off for a minute. But when you open your eyes, the upgrade process halted and you have a white screen with “invalid Customer ID” in red and no Android. You reboot, no go. You try to enter recovery mode, no go. Congratulations, you now have a shiny (semi-)bricked HTC Magic and you go to sleep feeling an utter moron for trying to flash an official RUU.

Step 4: Rescue
The next day you start looking for information on the secret craft of goldcard creation. You spend a couple of days trying to get your SD-card’s CID on your PC, but eventually ask a colleague to adb-shell into his device with your SD-card in it to get the job done (thanks Thomas!). You don’t bother downloading crypto-software to reverse the string for all the wrong reason, instead immediately heading over to the goldcard-manufacturing-webstie, write the disk-image to SD and you try to flash the RUU with the goldcard you just created. Damn, no go! You reverse the string manually, no go. You buy a new SD card (4Gb Sandisk), adb-shelling into your own cheapo Acer this time to get the CID and create a new goldcard, no go. Over a week goes by and you decide to have another stab at it and opnly then you see that the string should be hex-reversed, not reversed. You click the link to an online hexreverser, create a goldcard with that string and bingo, the RUU flashes!

Step 5: Enjoy
It looks like you’re back where you were at step 2; Android 1.5 with HTC Sense UI and no tethering, so you decide to install Cyanogenmod by first downgrading your radio & hboot and then -finally- flashing Cyanogen’s Android mod.

And there you have it, after only 2 weeks you successfully turned that old HTC Magic into a modern, fast and reliable Android smartphone. Android 2.2.1 that is, with ADWlauncher, tethering and Exchange-integration. Time well spent, except … Vodaphone has an official Froyo update for the Magic out as well and there’s already a tweaked ROM for it on xda-developers. You really should try that one out as soon as possible, now shouldn’t you?!

Exporting from Google is easy, but it generates one vcard-file with all you contacts in it, which the contacts app in Android 1.5 can only import the first entry from. To split up the contacts-file, Scroogle pointed me vCard list-file splitter, vcf-split for short, a Perl script from back in the days when Windows linebreaks apparently were sufficient evidence of the end of a vcard. But times and technology have changed and linebreaks have lost their former glory, meaning I had to slightly alter the script to watch out for a cryptic “END:VCARD” line to indicate the end of a vcard.

And the script goes a little something like this:

#!/usr/bin/perl
#
# vcf-split - split a .list.vcf file into many small .vcf files.
# Copyright (C) 2004  Raphael J. Schmid.
# Tweaked by Frank Goossens ("futtta") in 2011
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 1, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
#
# -- raphael.schmid@gmx.de
# -- futtta@gmail.com

use File::Basename;

if ($ARGV[0] eq "") {
  print "Usage: vcard-split <file to split>\n\n";
  exit;
}

$input=$ARGV[0];
$counter=0;

print $input;

open INPUT, $input or die $!;

while (<INPUT>) {
  open OUTPUT, ">> ".$counter."-".basename($input) or die $!;

  if ($_ =~ /END:VCARD/ ) {
    print OUTPUT $_;
    $counter+=1;
    close OUTPUT;
  } else {
    print OUTPUT $_;
  }
}

close OUTPUT;
close INPUT;

Who knows one day Google will send someone this way who has some vcf-splitting to do?

1. mod_cache ignores Cache-control if Expires is in the past (which it shouldn’t according to RFC2616), so you might have to unset the Expires-header.
2. mod_cache by default caches cookies! Let me repeat; cookies are cached! That might be a huge security-disaster waiting to happen; sessionid’s (that provide access for logged-on users) are generally stored in cookies. If a logged on user that request an uncached page, then that user’s cookie will get cached and sent to other users that request the same page. Do disable this by adding “CacheIgnoreHeader Set-Cookie” to your config
3. mod_cache by default treats all browsers like the one that triggered the caching of the object. In the field that approach can cause problems with e.g. CSS-files that are stored gzipped (because the first browser requested with header “Accept-Encoding: gzip, deflate”). If a browser that does not support gzipped content requests the same file, the CSS will be unreadable and thus not applied. The solution; make sure the “backend webserver” sends the “Vary: Accept-Encoding” header in the response (esp. for CSS-files). This will tell mod_cache to take different Accept-Encodings into account, storing and sending different versions of the same CSS-file.

So what do you need to know about jQote2 to get it working? Well, there’s 3 ingredients; data, template and javascript-code to put the data in the template.

The data can be fetched from an external source, e.g. this call to the iRail-api for departures from Brussels North.

The template is basically just HTML with some placeholders for your data:

<script type="text/x-jqote-template" id="liveboard_tmpl">
 <tr>
  <td class="left">
   <%= this.station %>
  </td>
  <td class="right">
   <%= this.time %>
  </td>
  <td class="right">
   <%= this.platform %>
  </td>
 </tr>
</script>

The javascript fetches the data using jQuery’s getJson, parses all departures in the template and adds the resulting HTML to an element in your DOM (in this case #liveboard’):

<script type="text/javascript">
$(document).ready(
	function() {
		$.getJSON(
			'http://api.irail.be/liveboard/?format=json&station=Brussel%20Noord&lang=EN&arrdep=DEP&callback=?',
			function(data) {
					$('#liveboard').jqoteapp('#liveboard_tmpl', data.departures.departure);
			}
		)
	}
);
</script>

Off course the UNIX-timestamp in this.time isn’t really usable, but we can easily add some javascript to the template, just before outputting the time, to fix that;

<% this.time=((new Date((Number(this.time))*1000)).toLocaleTimeString()).substr(0,5); %>

That’s right, use “<%” instead of “<%=” and you can mingle javascript in the template. To only show trains that have not left and to show departures including delay, the template looks like this:

<script type="text/x-jqote-template" id="liveboard_tmpl">
<% if (this.left!="1") { %>
 <tr>
  <td class="left">
   <%= this.station %>
  </td>
  <td class="right">
   <% if (this.delay!="0") {
    this.time="<span class=\"delayed\">"+((new Date((Number(this.time)+Number(this.delay))*1000)).toLocaleTimeString()).substr(0,5)+"</span>";
   } else {
    this.time=((new Date((Number(this.time))*1000)).toLocaleTimeString()).substr(0,5);
   } %>
   <%= this.time %>
  </td>
  <td class="right">
   <%= this.platform %>
  </td>
 </tr>
<% }; %>
</script>

Add some CSS and you’ll quickly have something like the demo you can find here. Just look at the code, it’s pretty straightforward and check out the jQote2 reference for even more info.

You’ve got no clue what I’m rambling about, do you? Well, allow me to explain;

• <noscript> is the html tag that identifies alternative content for user agents (browsers, mainly) that don’t or won’t do javascript
• Venus is a planet-like web application that aggregates rss- and atom feeds from a community or about a specific subject (see e.g. planet mozilla, planet debian and the much-loved planet grep)

So now you know the context, let me reiterate; Venus doesn’t treat noscript the way it should! It not only strips out javascript as it should (are you listening tt-rss?) but it replaces noscript-tags and all HTML inside with escaped HTML (with HTML-entities actually). And that, my beloved ones, means that the HTML that WP YouTube Lyte generates, doesn’t work properly on Venus-based planets.

So I started looking at the Venus source and mailed with Planet Grep’s Wouter Verhelst to solve this issue. At first sight the solution seemed pretty straightforward; Venus shouldn’t ‘escape’ noscript but should instead just strip the opening and closing noscript-tag. Wouter installed a small sed-filter I wrote and added noscript to the whitelist of Venus’s sanitizer (which is based on Universal Feed Parser) and … it did not work.

The problem apperantly is with another sanitizing component in Venus; html5lib. Sam Ruby, the developer of Venus, wrote on the mailinglist;

There are multiple sanitization passes involved here. [...] The html5parser seems to think that noscript is to be parsed as text only, which would result in the behavior that you describe.  Looking at the current HTML5 spec, it appears that this does not match the expected behavior — so perhaps that changed too.

So I started looking at html5lib and … well, I’m stuck, html5lib is a pretty complex beast for a smalltime non-developer to dive into. So earlier today I turned to the html5lib discussion list to ask how sanitization can be configured not to escape noscript, let’s hope someone will enlighten me. Because until then those poor Planet Greppers won’t be able to see (a thumbnail of) Al Jarreau’s great version of Take Five way back in 1976:

First of all, Drupal 6 doesn’t like reverse proxies. If you don’t want to wait for version 7, which should do better in this respect, you might want to look at Pressflow. This Drupal 6 “distro” has everything on board to work with reverse proxies. So install Pressflow (or try to apply this out of date diff to stock Drupal) and in the Performance-screen set “Caching Mode” to “External” and “Page Cache Maximum Age” to the number of minutes you consider a cached page valid. Voila, you’re done in Drupal (edit: almost, as you might also want to change the $base_url in sites/default/settings.php to reverse proxy URL after you configured Apache).

Next up: Apache! A simple configuration like this one should do the trick:

ProxyRequests Off
ProxyPass /rp_drupal http://localhost/pressflow
ProxyPassReverse /rp_drupal http://localhost/pressflow
CacheEnable disk /rp_drupal/
CacheRoot c:/TEMP/apacache
CacheDefaultExpire 3600

OK, this must surely work, no? Well it should, but it doesn’t! When setting your Apache-loglevel to debug you’ll see “not cached” entries in your error-log, with the following reason:

Expires header already expired, not cacheable

Expires in the past, what does Pressflow think it’s doing deep down in includes/bootstrap.inc?

// HTTP/1.0 proxies do not support the Vary header, so prevent any caching
// by sending an Expires date in the past. HTTP/1.1 clients ignores the
// Expires header if a Cache-Control: max-age= directive is specified (see RFC
// 2616, section 14.9.3).
drupal_set_header('Expires', 'Sun, 11 Mar 1984 12:00:00 GMT');
// [...]
$max_age = variable_get('cache', CACHE_DISABLED) == CACHE_AGGRESSIVE && (!isset($_COOKIE[session_name()]) || isset($hook_boot_headers['vary'])) ? variable_get('page_cache_max_age', 0) : 0;
$default_headers['Cache-Control'] = 'public, max-age=' . $max_age;

Darn, those Pressflow-guys seem to have read up on their RFC’s! And indeed, 2616 confirms that cache-control’s max-age overrules expires;

If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache.

Mod_cache’s code seems to take a much simpler approach; at line 503 it decides not to cache based on an Expires-header in the past, totally dismissing the potential presence of cache-control’s max-age.

else if (exp != APR_DATE_BAD && exp < r->request_time)
    {
        /* if a Expires header is in the past, don't cache it */
        reason = "Expires header already expired, not cacheable";
    }

But you’re not interested in code which does or does not adhere to whatever RFC some spec-buffs came up with, you just want to cache your frigging’ Drupal-site! Well, fear not little hacker-boy, here’s some Apache-magic to cure your ailments, to be copy/pasted in the config before ProxyPass and ProxyPassReverse:

<Location /rp_drupal>
     SetEnvIf Request_Protocol "HTTP/1.1" expires_overrule
     # homework: add a SetEnvIf to see if cache-control max-age is present
     Header unset Expires env=expires_overrule
</Location>

So there you have it, a rudimentary caching setup for Drupal (in the guise of Pressflow) using nothing but Apache’s mod_proxy and mod_cache. Now go do your homework and test and do some finetuning and test some more. Happy caching!