That's All Folks

Today marks the end of an era for me. After more than 4 years at Esendex I feel that now is a good time to move on to pastures new. It's my last day today, and this will be the last post of this blog as well.

I first set this up to chart the experiences and knowledge gained during my work at Esendex, and now that work has come to an end I feel it is also fitting that this blog should as well.

I shall keep blogging though. I recently remembered that way back in 2004 I reserved iandykes.blogspot.com so I've resurrected that one and intend to keep it updated from now on.

Cool CG Animated Short Film

A CG 3D animated short film, apparently created by just one person. Amazing level of detail, and raised a few smiles as well. Looks very polished and professional.

A Brief Introduction to REST

If you're looking for information on REpresentational State Transfer, then check out A Brief Introduction to REST at InfoQ. I particularly like:

The next principle we’re going to look at has a formal description that is a little intimidating: “Hypermedia as the engine of application state”, sometimes abbreviated as HATEOAS. (Seriously — I’m not making this up.)

Assigning Basic Authorization HTTP Header to HttpWebRequest

If you're making a call to a HTTP resource that requires a Basic Authorization HTTP header, you can use the following code:

HttpWebRequest request = (HttpWebRequest)WebRequest.Create("url-here");
request.Credentials = new NetworkCredential("username", "password");

Then post the request in the usual way.

The confusion comes because on the first call the HTTP header will not be present on the request. The framework is relying on the first call receiving a 401 response, with a WWW-Authenticate header present, giving a Basic realm=<realm-name> value. A second call will then be made with the correct headers in place.

If you are just consuming the resource, chances are the server will respond in a way that allows this behaviour. However, if it doesn't respond with a 401, or that 401 response doesn't contain the WWW-Authenticate header (or you just don't want to make 2 calls), then you have to manually add the Authorization header to the request:

byte[] authBytes = Encoding.UTF8.GetBytes("user:password".ToCharArray());
request.Headers["Authorization"] = "Basic " + Convert.ToBase64String(authBytes);

Writing XML with UTF-8 Encoding using XmlTextWriter and StringWriter

If you want to use XmlTextWriter to write XML into a StringBuilder you can create the XmlTextWriter like this:

StringBuilder builder = new StringBuilder();
XmlWriter writer = new XmlTextWriter(new StringWriter(builder));

But this generates a declaration on the resulting XML with the encoding of UTF-16 (the encoding of a .Net String). There doesn't seem to be a straightforward way of making this declaration UTF-8 in this set up.

You can, of course, use a MemoryStream instead of a StringWriter, and then use Encoding.UTF8.GetString(...) to convert the bytes to a string, but doing this made the resulting string have non-printable characters in it, which we don't want.

The solution is to subclass StringWriter and override the Encoding property. Sounds a bit overkill for a solution, but it works very well. Just create the following class (based on Jon Skeet's class):

public class StringWriterWithEncoding : StringWriter
{
Encoding encoding;

public StringWriterWithEncoding (StringBuilder builder, Encoding encoding)
:base(builder)
{
this.encoding = encoding;
}

public override Encoding Encoding
{
get { return encoding; }
}
}

Then use StringWriterWithEncoding instead of StringWriter in your XmlTextWriter.