Yes, the blog has moved to Wordpress. I finally needed something more extensible than Blogger.

Why Wordpress, anyway

Yes, why a PHP based system, with all the .NET posts?

Two main reasons.

First of all, it is feature-rich, has loads of plugins, runs fast, and is relatively easy to customize.
Second, my main server is still on Linux, for various reasons. It is not a terribly powerful box so while I can run a VMWare with Win2k3 it has some performance issues.

I was for a moment tempted to pick one of the Django blog engines and customize it but I do have some more interesting projects to work on. Pick your battles wisely, and choose the best tool for the jobs, that’s what I said.

I am redirecting the domain and the feed is already on Feedburner so there shouldn’t be any change needed to the address.

“REST” style AJAX calls can be cached by the browser if the server is not properly configured. For some services this is a good thing (think, a mapping service), but often it is a hassle.

The way I see it there are 3 ways to get around it:

• The “proper” way is to configure the caching on the server app. For example in ASP.NET use Response.Cache.SetCacheability(HttpCacheability.NoCache), or use the <%@ OutputCache %> tag.
• The “fix it from the client” way is to add a random parameter to the Javascript. This way the query is different every time. If the server can accept POST as well as GET you can also use a POST since those are not cached.
• The “lazy” way is to force a header from the server configuration. In IIS this is super easy:
  1. edit the properties of the directory that contains your script services
  2. go to HTTP Headers
  3. Add a custom header: name is “Cache-Control” and value is “no-cache”

Lots of conflicting information on this one… Most pages will recommend using

netscape.security.PrivilegeManage.enablePrivilege("UniversalBrowserRead");
netscape.security.PrivilegeManage.enablePrivilege("UniversalBrowserRead");

Or go to about:config and toggle the setting for signed.applets.codebase_principal_support.
This didn’t do the trick for me, in fact it appears it is NOT required when you want to debug local files.
The only thing I had to do was create a file user.js under the FF profile directory (\D&S\user\App Data\Mozilla etc) with following content:

user_pref("capability.policy.XMLHttpRequestToAnySite.XMLHttpRequest.open", "allAccess");
user_pref("capability.policy.XMLHttpRequestToAnySite.sites", "http://localhost");
user_pref("capability.policy.XMLHttpRequestToAnySite.sites", "file://");
user_pref("capability.policy.policynames", "XMLHttpRequestToAnySite");

There is a security implication though. Any HTML file open from the hard drive will be able to communicate with any web site. Unfortunately I was not able to restrict the “file://” URL to a specific directory (like “file:///E:/html_projects” or something like that). Because of that I may have to keep coming back to this file and turn it off when I am done debugging. Or debug from the localhost server.

OK, this is going to be really obtuse to anyone who hasn’t played with IHttpAsyncHandler, but might save me a headache when I try debugging the same problem in 2 months.

Initially I had thought that an asynchronous handler would execute “out of context”… that is, the process would be:

1. Create context, begin request
2. Invoke “BeginProcessRequest” from the handler
3. End request, destroy context (INCORRECT!)
4. Later on, when the handler finishes – return the result, but do not call End request again, since we are not on the same thread anymore

Looking back, this does not make much sense – funny how things tend to look SOOO obvious once you figured them out. But for some odd reason I thought the HttpContext would not survive accross different thread and so everything
had to happen on the initial thread.
Here is what really happens:

1. Create context, begin request
2. Invoke “BeginProcessRequest” from the handler
3. Go on and do stuff while the handler works
4. Once the handler finishes, call End request, and return the result – this could happen on a different thread than the one we started on!

One more note of interest – in the “BeginRequest” event, HttpContext will be available, but context.Handler is still null. Context.Request.Path is available, though.