Server error!
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there was an error in a CGI script.
If you think this is a server error, please contact the webmaster.
Error 500

Turned out that the .htaccess file in the root of the WordPress install had some gibberish in it.  It looks like this gibberish replaced some of the actual contents of the file.  I don’t know how it got there, but fixing the .htaccess file solved the problem.  So, that’s something to check if you are having this problem as well!

It turns out that if your SSL certificate is not trusted, attempts to use the Flash uploader to upload files will give you a cryptic “IO error” message.  In my case, this I was using Firefox when I first encountered this.  My SSL certificate is self-signed, and even though I added an exception for it in Firefox, the Flash uploader still fails.

Here’s what I learned about this problem after banging on it for a few days.

This isn’t a new problem.  There are plenty of people who have noticed this behavior with WordPress before.  In fact, there are plenty of people who have noticed this issue with SWFUpload, which is the tool that WordPress actually uses to do the Flash uploads.  Some of them point to a bug in Adobe Flash Player.  However, it’s actually because the SSL certificate on your server isn’t trusted by your operating system for some reason or another.

Flash doesn’t use your web browser to decide whether or not it trusts an SSL certificate.  Instead, it asks the operating system.  On Windows, you can add your self-signed certificate to the trusted root certificate store (right-click on your .crt file and choose “Install certificate,” and then make sure it ends up in that store).  This will make the certificate trusted by default in Internet Explorer, and in any other program that asks Windows if a certificate is OK.  Firefox (and other some browsers) maintain their own database of certificates and certificate authorities, but Flash will always check the central Windows list of certificates, no matter which web browser you are using.

(Note that Mac OS X and Linux also have a central location for trusted root certificates, so the same type of thing applies there.)

This is actually reasonable behavior on Flash’s part.  Firefox’s “certificate trust list” (or whatever you want to call it) isn’t available via the NAPI plug-in interface, so there’s no way for Flash to check to see if Firefox trusts a given SSL certificate.  It can, however, use the Windows API to check to see if the system trusts it.  And if an SSL certificate looks suspicious, Flash won’t send data over the https connection.  This is what causes the error.

So, how do we fix this problem?  There are a few possible solutions.

(1)  If you are using a self-signed certificate, add your certificate to your operating system’s list of trusted certificate authorities.  If you are using a certificate signed by a non-trusted authority (like cacert.org), add that authority to your operating system’s list of trusted certificate authorities.  Of course, this carries a small risk.  If your certificate is self-signed, and your private key were compromised, now someone would be able to fake messages that your computer would trust.  And if your certificate was signed by a non-trusted CA, now you trust all certificates signed by that CA, which may not be what you want.

Now, this doesn’t help you if you’re in my boat and you want to run multiple WordPress sites on one server.  You can get one of them working, but since you have to use the same SSL certificate for all of them (unless you have a unique IP address to run each of them on), any sites that don’t match the site that your certificate as for will still have the error, because the certificate won’t be trusted even if you add it to the list of trusted CAs if the site you are accessing doesn’t match the site in the certificate.  In this case, we need a different solution.

(2)  Have Flash uploads to your WordPress site not use SSL. Of course, this means that the files you are uploading won’t be encrypted during transmission, but maybe that’s OK with you.  I can think of two ways to implement this solution.  But here, I am going to begin to descend into the depths of WordPress.

(2a)  WordPress plug-in to disable SSL for the Flash uploader.

I have actually completed and published such a plug-in.  The file wp-admin/async-upload.php is used to accept uploads from the Flash uploader.  If the FORCE_SSL_ADMIN configuration option is set, WordPress will automatically bump you over to an https connection if you try to access this file via http.  So the first thing we need to do is keep that from happening:

• Add a filter to ‘admin_url‘ that removes the https from the URL to async-upload.php, whenever it is about to show up in a WordPress admin page.
• Add a filter to ‘wp_redirect‘ so that when WordPress decides that it needs to redirect you to an https session, the redirect is canceled if you are accessing async-upload.php.
• Modify the ‘auth_redirect‘ function so that WordPress does not bail after attempting to redirect you to https, if async-upload.php is the file you are accessing.

Now, async-upload.php can be accessed without using https.  There’s another problem, though.  WordPress has two cookies that it may use to authenticate you, one of them is referred to as AUTH_COOKIE and used for regular connections, and the other one is referred to as SECURE_AUTH_COOKIE and is used for https connections.  The idea is, the SECURE_AUTH_COOKIE will never be sent in the clear, so if you force SSL connections, there is no way that someone can hijack your authentication cookie, even if they managed to grab one from back when you were using a regular connection. (In fact, SECURE_AUTH_COOKIE is marked as for use with secure connections only, so your web browser won’t ever send it with a regular http request.)

Now, Flash doesn’t always send cookies properly, so WordPress packages up the authentication cookie that you are using and sends it along with the Flash upload request as a POST variable.  async-upload.php takes the cookie from the POST variable and stores it back in the COOKIE variable where it belongs.  However, since our admin session is SSL, but async-upload.php isn’t accessed via SSL, it stores the cookie that was sent in AUTH_COOKIE instead of SECURE_AUTH_COOKIE, and then it fails to authenticate you.  So, we need to…

• Modify the ‘wp_parse_auth_cookie‘ function so that WordPress notices the cookie in the POST variable, if you are accessing async-upload.php.

(By the way, this hack sends your SECURE_AUTH_COOKIE along with the regular http request to upload your file, so… so much for never sending it in the clear.)

Almost done.  Now, requests to async-upload.php are made by your web browser (not Flash) to view and edit information about the uploaded files, right after the uploads are done.  Because the SECURE_AUTH_COOKIE is marked for secure connections only, your browser won’t send it along with these requests, so you won’t be able to view or edit file data right after you upload the files.  To work around this, we take the login cookie as acceptable credentials to do this.

• Modify the ‘auth_redirect‘ function to look for the login cookie and accept it as good authentication, if async-upload.php is the file being accessed.

(This means that if someone hijacked your login cookie, they might be able to mess with your file data.)

So, we add a couple of obscure security holes to WordPress and the Flash uploader is working with your bad SSL certificate.  Is the tradeoff worth it?  That’s up to you.

Oh, but I said I could think of two ways to ditch SSL for the Flash uploader…

(2b)  Modify WordPress itself for a more clean workaround.

The ‘auth_redirect‘ and ‘wp_parse_auth_cookie‘ functions mentioned above are both pluggable.  However, the functions we’d need to modify for a more clean solution are not.  How might a more clean solution work?

Obviously, the files you are uploading with the Flash plug-in won’t be encrypted.  However, we’d like anything else that is transmitted unencrypted to be useless in hacking into your site.  The SECURE_AUTH_COOKIE should never be sent in the clear, and the login cookie shouldn’t be sufficient credentials for messing with the data associated with your uploaded files.

I think the solution to this is some sort of key exchange between the application running on the server and your web browser (using PHP on the server and Javascript in the browser) to come up with a random, secret phrase that can be sent along with requests to async-upload.php as a POST or GET variable.  A challenge-response system would need to be used along with this so that the secret wouldn’t be transmitted in the same form twice (to prevent replay attacks).

I know this sounds a little vague, but I have an idea in my head about how it would work.  Maybe I will take a stab at implementing it and present it to the WordPress devs, if I ever get the time and motivation.

But it seems like an awful lot of trouble to go through just to work around this edge case.  Just fix your SSL certificate!

<input type="hidden" id="_wp_unfiltered_html_comment" name="_wp_unfiltered_html_comment" value="xxxxxxxxxx" />

This code only shows up if you are logged in, and allows your comments to bypass HTML validation, so you can use whichever HTML tags you like.  What is causing the problem is the “id” attribute.  According to the XHTML standard, the ID must start with a letter, and here it starts with an underscore.

There’s some discussion of this over on the WordPress end, with various opinions.  Depending on which spec you read, it might be valid XHTML.  It’s not super-critical, since no one sees the invalid code besides you.  Still, it looks like it might be fixed in WordPress 2.9.  But until then, my page is going to fail against the validator addon I have in my web browser?

What’s annoying is this code is not part of the WordPress theme, so you cannot fix it without modifying WordPress itself.  That’s not really acceptable, because you’d have to repeat the modification every time a new version of WordPress comes along.

Well, actually, you can fix it in your theme, it’s just a little tricky.  To do it, open the comments.php file in your theme, and find this line:

do_action('comment_form', $post->ID);

Replace it with this:

ob_start();
do_action('comment_form', $post->ID);
$output = ob_get_contents();
ob_end_clean();

echo str_replace(' id="_wp', ' id="wp', $output);

This will strip the underscore from the beginning of the “id” attribute.  Because the do_action() function prints stuff out, we have to capture the output, modify it, and print it.

Since the underscore is still part of the “name” attribute (which does not fail validation), and the “name” attribute is used to build PHP’s $_POST array, I do not think that this modification will have any affect on WordPress’s operation — seems to work as intended when I test it.  And now my pages will validate as well.  Great!

Welcome to the new aaron-kelley.net.  I’ve migrated all of my previous content to WordPress, which now powers my site.  This makes the site much easier to manage than the makeshift CMS that I had in place before.  Hopefully, now I will be able to find the time to add some useful content.

There will be some changes to the appearance/theme over the next few days and weeks as everything gets settled.  However, all of the old content is now available here, and the site is completely usable.

WordPress is a pretty cool platform to build a web site on.  It’s really starting to take off now, too.  I’ve known about it for a long time, but some of the features that made me decide to go ahead and move only came in as of version 2.7 ot 2.8 (or, in the last 8 months).  I recommend looking into it if you are looking to build a simple site; it’s not only for running blogs, you can manage static content pages on it as well, and it is pretty easy to extend if you know any PHP.  There’s even chatter about media albums coming to WordPress in the near future, so I’m hopeful that I’ll be able to move all of my content from the photo gallery into this site, just to have everything in one place.  More on this later.

Probably, next up will be a series of blog posts on Ubuntu Linux — the operating system in general, and fixes to some specific issues that I’ve come across as well as other general tips.  I’ve been collecting these since I switched to Ubuntu last November but never got around to posting them online.  How can I not, now that it is so easy for me?  I’ll also be posting whatever random useful information that I come up with — after all, my main audience is Googlers who find a page on this site while looking for something specific, and that’s how I plan to run things for a while longer.