We left off at the end of my last article being able to grab and print a GET request from a web page. There were a few issues with the way we did things however. Firstly, we were reading in a buffer the size of the maximum possible buffer size, so when we were printing out our request it was followed by a ton of whitespace. In order to fix this I tried to trim the string for whitespace, this did not work.

It turns out that if you take a look at the ASCII characters of the string you get in the byte buffer you will notice that there are a ton of 0’s at the end of the string. This corresponds to the null character. When Receive() grabs data from the socket, it will fill up the remainder of the array with null characters, so to trim the string we simply use

    convertedData = convertedData.Trim('\0');

Our next issue is how to parse the request we get. Basically all we want to do is find out what page/resource they are looking for and then check to see if that page exists, if it does respond with it, otherwise respond with nothing. However, there is a special case we have to look for. When a person browses to a site like www.blah.com the first get request is always going to look like “GET / http/1.1″, followed by the rest of the GET request. What this means is that the browser is looking for the “/” file or resource. By convention this “/” is always index.html (unless otherwise defined) so we have to check for this in our server.

So I created a method to parse our get that just looks at the first line of the request and returns the proper resource.

private static byte[] ParseGet(String getRequest)
{
    // Set the directory to server from to desktop\sites.
    var path = Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory) + "\\sites";
    var words = getRequest.Split();
 
    if (!words[0].Equals("GET"))
    {
        return new byte[0];
    }
 
    if (!words[1].Equals("/"))
    {
        return !File.Exists(path + words[1]) ? new byte[0] : File.ReadAllBytes(path + words[1]);
    }
    else
    {
        var bytes = File.ReadAllBytes(path+"\\index.html");
        return bytes;
    }
}

Our final problem is that currently, we can only accept one request at a time. We listen on the port until a request is made, then we process that request until completion, then we listen again. We want to be able to handle multiple requests concurrently, so we must thread our request procession. To do this, we move our request processing out into its own method:

private static void ProcessRequest(Object o)
{
    var acceptedSocket = (Socket) o;
    // Read request.
    var data = new byte[acceptedSocket.ReceiveBufferSize];
    acceptedSocket.Receive(data);
    var convertedData = Encoding.ASCII.GetString(data);
 
    // Receive() fills the buffer with nulls after the data has been read.
    convertedData = convertedData.Trim('\0');
    char[] delimiters = { '\r', '\n' };
 
    var lines = convertedData.Split(delimiters, StringSplitOptions.RemoveEmptyEntries);
    Console.WriteLine("{0}", convertedData);
    var outData = new byte[0];
 
    // Write response.
 
    // Make sure there is data to parse.
    if (0 != lines.Length)
    {
        outData = ParseGet(lines[0]);
    }
 
    acceptedSocket.Send(outData);
    acceptedSocket.Close();
}

You will notice from the above code that ProcessRequest takes an Object instead of a socket. This is too bad, it would be nice if you could do that
ParameterizedThreadStart requires a method that takes an object and I could find no way around this.

Our final run method now looks like this:

public void Run()
{
    // Set up socket for listening.
    var hostIp = (Dns.GetHostAddresses("127.0.0.1")[0]);
    Console.WriteLine("Listening on {0}:{1}", hostIp, Port);
    var endPoint = new IPEndPoint(hostIp, Port);
    TcpSocket.Bind(endPoint);
 
    while (true)
    {
        TcpSocket.Listen(BackLog);
        var processThread = new Thread(new ParameterizedThreadStart(ProcessRequest));
        processThread.Start(TcpSocket.Accept());
    }
}

If you create a directory on your desktop, place an index.html in there and then navigate to http://127.0.0.1 it will now
serve your very own index.html. Here is mine:

If you would like to check out the code, it is available here: KevServer

The job requirements included extendability, maintenance, minimal overhead, and it had to work with the current code, i.e. I couldn’t go and redesign the entire system. There were already hundreds of forms in the system with thousands of fields requiring validation. My first task was to explore the different possibilities. I came up with a few various schemes for both client side and server side validations. I opted to go with a client side solution for various reasons, including the fact that I could update the page with any error messages without ever needing to contact the server.

The major problem that I had to address was how to insert my validation functions within the already created web forms in an easy, extensible way. At the time I had been playing around with a JavaScript library known as jQuery. I had very little experience with it, but it seemed very interesting. Cam had also recently begun using jQuery and was big on the library.

One of jQueries big features is easy manipulation of the DOM tree. jQuery ingeniously makes use of CSS Selectors to wrap a group of elements in a jQuery wrapper. If you have never used CSS selectors, I HIGHLY recommend taking a look at them.

Using jQuery, the following simple code:

$('.foo')

returns an array of all DOM elements with the attribute class=”foo”. You can then iterate over this wrapped set in a number of ways. This is immensely powerful. Additionally, jQuery will recognize custom attributes.

The code:

$('input[required=true]')

will return all input elements with a custom attribute required=”true”. What this means is, if you have in your HTML a text field like this:

<input type=”text” required=”true”>

The jQuery code above will find that element and return it in a wrapped jQuery array. I used this as the basis for my validation system.

What I did, was define a set of custom attributes, and a set of JavaScript functions based on requirements given to me by the hiring company. Then I created a validate() function which sequentially called all of my JavaScript functions. This validate function was meant to be called in an onSubmit() but could be called anytime.

If you ever wanted a field to be validated, you simply added my custom attributes to its HTML markup. So for example, if you wanted a field to be marked required, you simply went to that field and added required=”true”. If you wanted a field to be checked for a valid integer, you went to the field and added type=”integer”.

The beauty of this approach is that it allows a field to be marked with an arbitrary number of validations. And removing validation is as easy as removing the custom attribute. Additionally, if you add a new function to the set of JavaScipt functions, all you need to do to add it to a field is add the new custom attribute.

The way this works is, when the person submits the form, the validate function is called. The validate function uses jQuery to parse the DOM tree and iterate over the results. So within the validate function, the first function looked something like this:

$('input[required=yes]').each(function(n)
{    
 
  // validate the required strings.
  var str = validateRequired(this.value, $(this).attr('field_name'));
 
  // If we had an error, concatenate it into the error string and add the errorCase
  errorStr += errorCheck(str, $(this));
 });

What this did was, it searched the page for any input elements with the custom attribute required=”yes”. It then iterated over that set and passed the value into the JavaScript function validateRequired() which checked whether the field was non-empty. It then returned an error string from a function that properly formatted error messages.

Each method concatenated an error string when there were any errors, and at the end of the validate() function if there were any error messages it printed them to the screen in a custom div. Otherwise, it allowed the submit to go through.

This was done for every type of validation, even if there was no elements with that custom tag within the current page. This makes it easy to simply add new validations on the fly. Also, all the JavaScript functions are in a central place and are easy to modify/update and have it filter through the system automatically.

This solution worked perfectly as it was easy to implement and fit the requirements perfectly. The client was pleased and everything worked out.

This may not be the way I would design the validation system today, but it was an excellent choice at the time.