Today was actually the first time (that I can remember) I have come across the following error message:

"Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack"

Unfortuntely, today also happened to be a very long day following a very long night (working until 5am last night).

So when this error appeared in a fresh page, based 90% on my previous code I was stumped, angry and frustrated.  Thankfully for me the error was simple to rectify, however it is important to note the error has a purpose rather than it being a bug.

This error crops up when terminating the Response to a page either through Response.End, Response.Redirect or Server.Trasnfer

You may not even notice the error 95% of the time that it occurs.

I had the lethal combination of a try-catch block and a Response.Redirect.  I think I'll explain the significance of the error first and then the simple work-around.

Basically, the Response object is a .NET wrapped set of code that has a certain life-path.  This path is supposed to end with a Response.End (either explicit or implied) that passes execution to the Application_EndRequest method.  When the correct path is not followed, a ThreadAbortException is thrown.

I moved my Response.Redirect out of a try-catch block and appended the optional "terminate execution" parameter of "false" as follows:

Response.Redirect("going-somewhere.aspx", false);

This alleviated my problem and I was able to go back to swearing about something else that wasn't working as expected.

Microsoft's explanation and fixes are listed here: ThreadAbortException when using Response.Redirect

My colleague was getting frustrated earlier when trying to replicate the effects of a form from one website into a different website.  She was using a HTML input tag set to type=image, as follows:

<input type="image" src="images/image-name.gif" alt="Send Message" value="Submit" />

Now I don't get involved in HTML that much anymore so I was curious when she said that although the form was posting back when she clicked on the image, the server-side PHP script wasn't recognising the postback.  In fact, the page was just re-rendering.  My colleague has used this same simple HTML on numerous occassions before including a GET-based PHP form to another page.

After a trawl around Google we found suggestions from the HTML definition that you should specify the HTML action in the "value" attribute.  This we did as above to no avail.

Now since I am always suspicious of PHP (amongst other technologies) for handling things just that little bit different I looked for any PHP-related posts on the subject.

 Turns out this is actually because IE (from version 6 onwards at least) doesn't send the value for a HTML input of type=image.  Not like Microsoft to adopt just part of a standard I hear you say with you tongue in your cheek.

Now since the type=image is supposed to return x & y co-ordinates from the browser there is a simple work around.

The server-side code would normally receive the following data from a HTML input tag where type=image:

control_name => value

control_name_x => x co-ord

control_name_y => y co-ord

Since with IE you don't get the value returned you can simply test for the existence of x or y as follows:

 <?php

if (isset($_POST["control_name_x"]))

{

// form submitted 

}

?>

So there we go, PHP not to blame after all.  What was I thinking?

 

Although I have researched SQL-Injection attacks before, as with any securty issue its important to see if new attacks have emerged.

Since I mainly develop in .NET and T-SQL a lot of the recommended input-checking etc is the same story as usual: parse input and where possible limit the characters allowed.

For many developers these kind of things are ignored initially because of the trial and error approach that they use in developing. I develop class-based and tier-based solutions and therefore any cleansing necessary can be easily implemented without duplication of code.

As a recommendation to all working on new projects, I would recommend creating separate classes or layers for data-pulling and pushing (to and from the DB). In this way, most cleansing can be done in one place and the format of the destination fields can be used to determine the limit of characters for submission to the database.

Where possible use Stored Procedures and very importantly, handle errors so no clues are returned to those attempting unauthorised access. Secondly, log failed attempts, the contents of those attempts and their originating IPs so you can adapt any methods you have in place for dealing with them.

All too often in the search for better ways to improve ranking those of us in the business of doing many different tasks are guilty of forgetting the basics.

My girlfriend remarked something to me yesterday about needing to decide on keywords before using them in descriptions - which is of course correct. But there are many times when I haven't stopped to concentrate on the placement of keywords in the description that match keywords exactly as used elsewhere.

The truth is that I don't spend enough time concentrating on the simpler aspects of SEO before running off into the off-page paradigm.

I think the main reason I started this blog was to note to myself the things that I learn as I go on.

Coming from a MS Server background, each day I amass more knowledge and remember less of what I used to know.

Many times I have searched the web for an answer and ended up having to figure it out for myself. This blog will give me the opportunity to remember those things and pass on the experience.