Het Bijstere Spoor

A quick update about CSP. Browsers are well on their way to all adopt the specification.

An early draft was already adopted by Firefox 4, and I just found out that it's also working in Chrome, Safari and IE 10.

IE10 and FF are using the following header:

X-Content-Security-Policy: default-src 'self'

While Safari and Chrome use:

X-Webkit-CSP: default-src 'self'

When the specification is finalized, the X- will be dropped, and it will simply be 'Content-Security-Policy'.

A call for support

Hi Developers! Start implementing this feature! It's important for the future and security of the web. The web's biggest vulnerability, from what I understand, is still XSS, but if people start to properly implement CSP, XSS can effectively be a thing from the past.

So even if you don't want to risk using CSP on a production environment, at least consider adding the headers in your development environment. It will force you to write better code, by not embedding javascript directly into the HTML source. By considering this right now, you will also make it much easier if you do decide to adopt CSP at some point in the future.

I'm implementing CSP full-on in a new project, and one of the things I've noticed already is that some of the javascript we embed from 3rd parties use eval() and inline html events (onclick & friends). For the sake of security we will most likely decide to only use 3rd party code if they are indeed CSP-compatible.

In my work I have to look a lot at the IETF rfc documents, and I always have to jump through a bunch of hoops to find the document I want. Google often links me to the text version, and often I'm looking at obsoleted versions of documents when a new rfc has been published.

Well, so I created a simple OpenSearch provider to solve this. It does exactly what I need, and I only tested in Firefox. If it's useful to anyone else, you can add the provider from rfcsearch.phpfogapp.com.

It works with a simple hardcoded list of known keywords, and it will fall back to "Google's I'm feeling lucky" if it doesn't know the keyword. Feel free to fork it or laugh at my source code.

My PHP Advent article just got published. It's a list of best practices around dealing with dates and times in PHP. Have a read and tell me what you think. Also, be sure to follow @phpadvent or subscribe.

While profiling SabreDAV, I noticed a few times more than half of the request time was spent in the autoloader.

So instead of autoloading, now I prefer to unconditionally include every file for each package (there are 5 packages). For a while I manually maintained these files manually, but a while back I automated this process.

This is how you run it:

phpincludes . includes.php

This will generate a file such as:

<?php
 
// Begin includes
include __DIR__ . '/Interface1.php';
include __DIR__ . '/Class1.php';
include __DIR__ . '/Class2.php';
include __DIR__ . '/Class3.php';
// End includes

You can edit everything before "// Begin includes" and after "// End includes". Subsequent edits will only replace the lines in between those comments.

The script will automatically expand classes and interface dependencies and load them in the correct order. It also has support for a PHP 5.2-compatible syntax (dirname(__FILE__) instead of __DIR__).

If you like it, head over to github, or install it with:

pear channel-discover pear.sabredav.org
pear install sabredav/PHPIncludes

I've finally taken the plunge and moved the SabreDAV source from Google code to GitHub.

The main reason is that I'm hoping that people are more likely to fork and contribute. This was possible as well on googlecode, but I think people had a bit more trouble getting used to the feature.

Mercurial is still the best source control system, but I feel switching to Git was worth it, solely for GitHub.

You can find the source at https://github.com/evert/SabreDAV.

Interesting news today. The Olson database, which is used in countless operating systems and other software (including PHP) has been shut down due to a Copyright claim.

Details, which I won't repeat here can be found on Stephen Colbourne's blog.

While working on an application I ran across a huge bottleneck which I isolated down all the way to the use of the iconv_substr function. If you ever wonder which is better to use, this should help your decision:

Benchmark script

<?php
 
$str = str_repeat("foo",100000);
$time = microtime(true);
 
iconv_substr($str,1000,90000,'UTF-8');
 
echo "iconv_substr: " . (microtime(true)-$time) . "\n";
 
$time = microtime(true);
 
mb_substr($str,1000,90000,'UTF-8');
 
echo "mb_substr: " . (microtime(true)-$time) . "\n";
 
$time = microtime(true);
 
substr($str,1000,90000);
 
echo "substr: " . (microtime(true)-$time) . "\n";
?>

The results widely varied between machines, operating systems and PHP versions; but here are two results I recorded.

First, PHP 5.3.4 on OS/X:

iconv_substr: 0.014400005340576
mb_substr: 0.00049901008605957
substr: 3.7193298339844E-5  # Note the E-notation, this was actually something like 0.00003 seconds.

As you can see iconv took 0.01 seconds, while mbstring took only 0.0004 seconds. Already a significant difference (2800% slower), but the difference became more apparent when running this on a Debian box with PHP 5.2.13.

iconv_substr: 8.3735179901123
mb_substr: 0.00039505958557129
substr: 4.8160552978516E-5

Yup, it took 8.3 seconds. That's an increase of over 2100000%. So next time you're wondering which of the two may be smarter to use, this may help you decide.

Important to note that OS/X uses libiconv as the 'iconv implementation' and my Debian test machine 'glibc', so it looks like libiconv is much, much faster than glibc. mbstring still leaves both in the dust though.

I'm interested to hear what your results are, especially if they differ.

Interesting news passed by today, apparently a fraudelent SSL was issued by Diginotar, effectively allowing wrong-doers to perform MITM attacks for all google services. Normally fake certificates will clearly error up in the browser, but because Diginotar is a trusted CA (certificate authority) it won't.

This says something about how much we can trust SSL. All it takes is one corrupt employee at a trusted CA and it falls down. CNET has pretty good coverage of the story.

Over the last month I've been working hard at the Atmail office in sunny Australia to get CardDAV support built into SabreDAV; and I've finally completed all the steps to do this release.

So there it is, CardDAV. Unfortunately there are not yet a lot of clients who actually use it, and it mainly comes down to iOS and OS/X, but I've been asked about CardDAV a lot and suspect more people will become interested in this protocol (especially if more vendors start supporting it).

So that's pretty much it; head over to download page to fetch a copy. I've had to break a couple of minor api's, you can read about those in the migration document.

• Full changelog
• Migration document for 1.4.x users
• CardDAV documentation

I tried my best to write good documentation for the new stuff, but it's always very time consuming, and not as good as I'd like If you have time and the will to write more, let me know!

Lastly, a big thank you to Nick Boutelier for creating the new SabreDAV logo!

Well, I just checked my calendar and it turns out I've been blogging for exactly 5 years now. This is the only time I allow myself to make an off-topic post, so here goes:

An exciting year indeed, with lots of change. Moved back from Korea to the Netherlands, started a new job, spoke at a conference, and I've met lots of bright and interesting people.

I've been royally sucking at blogging though. Only 22 posts in the entire year. Worst year to date :) I really should get back into the game, but I steadily feel that the things I'm running into from day to day becomes less relevant to blog about, as there has usually been someone else with a much better description of what I'm really trying to say.

Maybe that's just an excuse though.. If you're still reading, thanks for sticking with me!