ServiceStack Request Filter to Require Secure Connection

This code snippet provides a Request Filter to make sure your ServiceStack services are being called via HTTPS.  If not, it returns a 403 code.

public class SecureRequestFilterAttribute : Attribute, IHasRequestFilter{    public IHasRequestFilter Copy()    {        return this;    }    public int Priority    {        //        // By setting priority to -100, this filter will be applied first.        get { return -100; }    }    public void RequestFilter(IHttpRequest req, IHttpResponse res, object requestDto)    {        //        if (!req.IsSecureConnection)        {            res.StatusCode = (int)HttpStatusCode.Forbidden;            res.Close();        }    }}

Advertisements no response

Last time I wrote about my switch from GoDaddy to  The process wasn’t as smooth as I wanted it to be.  Though it wasn’t so bad.  The issue was on‘s side, but GoDaddy’s support was actually pretty good and helped me out.

Recently I wanted to forward some sub domains.  I couldn’t find the instruction any where on their website.  So I decided to email their

Hi, how do I forward subdomains?  e.g. say I own, I would like 

After three days of response I sent them another email.

No response?

It’s been over two weeks and still no response from their support.  The issue I wanted help with was a minor one (I even forgot about it for two weeks).  But the main problem I have now is their lack of response to their paying customer.  
This is strike one for in my book.

Transfering Domain Names

I've been using Go Daddy for some time now. ??For the most part, their pricing was the only thing keeping me there. ??I really disliked their UI. ??Every time I tried to change something, I had to double and triple check to make sure nothing was added/changed by accident.

Recently Alex registered his site ( with ??Their UI was much cleaner and simpler. ??Everything was straight forward. ??The pricing wasn't the cheapest, but it was competitive.

Today I decided to transfer three domains from Go Daddy to ??Two names transfered without a hitch. ??But unfortunately one ran into a few problems. ??First off the authorization code from Go Daddy for this problem name contained two percent signs (%). ?? didn't like it and said the code was invalid [1].

I called up Go Daddy customer service and talked to Lisa. ??She spoke fluent English and was very understanding. ??She changed the code and resent it to me. ??The new code contained two ampersands (&) (in the exact same places as the %s). ??I gave it a try. ??Still, rejected it. ??Lisa changed the code and resent it to me again. ??This time the code contained two open parenthesis ((). ??Fortunately decided that the code was valid. ??(Note: I give thumbs-up for Go Daddy's customer service.)

The next step in the transfer was also problematic. ??For one of the domain names, I had set the admin email to to take advantage of gmail's filtering system. ??But didn't like that either and stripped the address down to ??So it sent the transfer notice there. ??Naturally I didn't receive it. ??I had to change the email in Go Daddy, then get to reacquire the data (which apparently you can only do every 4 hours).

The transfer process wasn't as simple as I had hoped. ??But now that everything's moved over, things should be good for a while.

These are the format of the authorization code for the problem domain name (1st, 2nd, and 3rd tries). ??Makes you think…


IE stripping quotes in html

I was working on some javascript and html DOM manipulation. Everything was going fine and working well on FireFox. ??But it would crash on Internet Explorer. ??After spending some time tracking the bug down, it turned out that IE was stripping out quotes from html tag attributes if it thought the values were singular.

The fix was to put a space in front of the value such as

<p class=” abc”> ->
<P class=” abc”>

instead of

<p class=”abc”> ->
<P class=abc>

PHP Disappearing Errors

I was installing a wiki on my Ubuntu machine (running nginx, FastCGI, and PHP) when I ran across an interesting situation. First I installed the wiki in the site root directory. After reading this, I decided to move it to /wiki/. That’s when the problem started.

The errors that I got were nothing special: “Fatal error: require_once()“. After inspecting it some more, it turned out that wiki (specifically dirname(__FILE__)) was using the old path.  When I went into the code and echoed dirname(__FILE__), I got the new and correct path. The funny thing was that it seemed to have fixed that particular require_once() and the next require_once() error showed up. I did the same thing again: echoed dirname(__FILE__) and that error went away, and the next one showed up.

I spent a few minutes googling but didn’t find anything useful. I figured it probably had to do something with PHP and/or FastCGI caching. So I just rebooted the server (good thing it’s not a production server).

Voila! The wiki works.