How to ignore global Ajax error handler for user aborted requests using jquery

We had this situation in one of my project, where we wanted to bypass the jquery global Ajax error handler if user aborts the Ajax request by navigating away from the page (for example, by clicking a link on the page)

I tried various options but none seem to work. Finally, I came across one solution, that seem to work perfectly well for my situation.

The idea behind this perfect solution is,

• Bind the "beforeunload" event on the window object.
• In the event handler, set a global variable to indicate that the page is being unloaded. 
• In the global Ajax error handler, do not take any action if the above global variable is set.
• In all other cases, perform the actual Ajax error handling.

Lets quickly look at the JS code as well.

The code is pretty self explanatory and well documented.  That's about all it takes to get the job done! 

The thrill of being a developer - Fixing the problem of weird URL's

There are days when as a developer, I feel bored, bored to death, angry, happy, sad and many other emotions.  But there are a few days in life of a developer, when you feel truly thrilled!

Recently, one such thrilling day occurred in my life.

In one of the project, we were facing a weird and interesting issue in production.  The application server would get weird requests from the browser.  The weird thing about these request was that, the parts of the requested URL would be valid but, the end part would contain some weird html tags!  Since the resource would not be found on the server, app server would log the request and return a 404 error page.

For e.g. one such log message was:

The request that browser sent was:

The above URL is to fetch jquery.maskedinput.min.js file.  

Generally when an issue is reported by the QA/Client, I already have some idea as to what could have caused the issue.  But, this issue was special.  When I first saw these error, I was completely blank.  I had no idea what so ever why would something like this every happen!

We were using a pretty common Java stack.  Spring MVC and Hibernate, app was deployed on Weblogic server.  I had used these frameworks in so many other projects, but never ever faced an issue like this.

The most frighting part was, I had no idea what was the end user impact.  Was the user logged off?  Was he shown any error?  Did he see a garbled page?  No idea at all!

Coming back to the issue.

Yes believe it or not, the above request is to fetch the jquery masked input javascript! Notice that the beginning part of the URL is valid, but what gets added at the end is really not expected.

From where did

text get appended to the URL?

Digging a little deeper, I found something totally bizarre.  Turns out that the text

is present in the same page after some 4096 bytes!

How is it possible that something that comes after a few thousand bytes gets appended to the request URL of jquery.maskedinputments.min.js?

After two and half days of hard core googling, trying hundreds of different things with the script tag, the textarea tag, using different permutation combinations, and countless hours of analyzing the server logs over and over again, finally I have found a credible explanation to weird URL’s issue we were facing.

It happens because of a bug in IE8’s Lookahead Downloader.  The problem has nothing to do with the application!

What are you talking about?  Explain me in detail:

Following is an extract from this URL: http://blogs.msdn.com/b/ieinternals/archive/2009/07/27/bugs-in-the-ie8-lookahead-downloader.aspx which describes the bug in full detail.

---

Lookahead Downloader is used to quickly scan the page as it comes in, looking for the URLs of resources which will be needed later in the rendering of the page (specifically, JavaScript files). The lookahead downloader runs ahead of the main parser and is much simpler-- its sole job is to hunt for those resource urls and get requests into the network request queue as quickly as possible.

The problem here is that there are a number of tags which will cause the parser and lookahead downloader to restart scanning of the page from the beginning. One such tag is the META HTTP-EQUIV Content-Type tag which contains a CHARSET directive. Since the CHARSET specified in this tag defines what encoding is used for the page, the parser must restart to ensure that is parsing the bytes of the page in the encoding intended by the author. Unfortunately, IE8 has a bug where the restart of the parser may cause incorrect behaviour in the Lookahead downloader, depending on certain timing and network conditions.

The incorrect behavior occurs if your page contains a JavaScript URL which spans exactly the 4096th byte of the HTTP response. If such a URL is present, under certain timing conditions the lookahead downloader will attempt to download a malformed URL consisting of the part of the URL preceding the 4096th byte combined with whatever text follows the 8192nd byte, up to the next quotation mark.  Web developers encountering this problem will find that their logs contain requests for bogus URLs with long strings of URLEncoded HTML at the end.

Impact on the end user:

Generally this has no direct impact on the visitor's experience, because when the parser actually reaches a tag that requires a sub-download, if the speculative downloader has not already requested the proper resource, the main parser will at that time request download of the proper resource.  Hence,

• The visitor will not notice any problems like script errors, etc
• The visitor will have a slightly slower experience when rendering the page because the speculative requests all "miss"
• IIS/Apache logs will note requests for non-existent or incorrect resources

The fix:

The fix is simple.  We needed to apply a IE8 Cumulative Update (KB980182) patch on the client machine’s which have this problem.

---

When I read this post, I was just stunned!  Problems like these truly blow your mind away!

Today, when I think about the problem, I realize that, its because of problems like these, I love being a Developer!

True developers, solve Real problems!

How to accept only strict dates using javascript validations

Well, well, well yes there are a thousand (or even more) date pickers around to help users to choose a date.

But recently in a project, I was faced with a situation where requirement was, to allow user to choose a date via a date picker but also allow them to type in the date if they wish to do so!

Hummm.... I know its a standard requirement. We where using JQuery as our javascript framework and JQuery-UI for the date picker.

Showing the date picker is a child's play all we have to do is:

• Include the jquery library
• Include the jquery-ui library and css
• Invoke the datepicker method on the chosen input field

But allowing user to type in the date is a bigger challenge.
Why? Because they can type in any random value which may not be a valid date.

There are lots of plug-ins available in jquery to stop users from entering chars in date fields etc. Thats easy you see! But the problem is making sure user enters a valid date.

Lets assume that the date format we are using is mm/dd/yyyy.
If the user enters 13/01/2010, clearly its an invalid date since we have only 12 months so far!

But the javascript Date class is very very lenient and it converts the date 13/01/2010 to 01/01/2011 which is a valid date.

And hence for javascript 13/01/2010 is a valid date. But for us, humans its an invalid date!

So how do we validate such invalid inputs and show errors to users?

How do they do it!

The approach I take is as follows. I use two level of defense strategy and heres what I do

• Step - 1: Use the javascript Date class to find whether user has entered a valid date? If date parsing fails then show and error to the user. This is our first level of defense
• Step - 2: If we are able to parse the date, then we need to verify if its a valid date. If its not we show an error to the user. This is our second level of defense.

Step - 1 is easy and I am not going to show it.

Step - 2 is done this way

Basically, we first let javascript parse the date entered by user and then we split the date into parts and then verify that

• The month entered by user is the same as the month held by the parsed date
• The day entered by user is the same as day held by the parsed date
• The year entered by the user is the same as the year held by the parsed date

If any of the above conditions fails, we return and error to the user.
If all of the above conditions are true, then user has entered a valid date

The Sample Code:

If you try the above code we get two alerts the first one is Invalid Date. and the second one is Date is valid. and that is exactly what we want!

Mission accomplished!