Category Archives: AJAX

Getting Access Is Denied with JQuery Ajax in IE 9

I recently moved from Prototype and Scriptaculous to JQuery. The transition is not very smooth but wasn’t very painful either. Actually much of it is straightforward except for Drag and Drop. Anyway, everything was done and it worked fine in Firefox, Safari and Chrome. But not so with IE.

There is an ajax call which kept giving “Access is Denied” error with IE. Searching on the web indicated this is something to do with Cross Domain AJAX call (some reference to CORS). But in my case the call is to the same domain. I was scratching my head on what’s wrong and when I changed the minified javascript to the regular script the debugging became easy. The error was in buildFragment. So, once I started searching for the same Access Is Denied along with buildFragment, I got a link to this exact issue which actually has been fixed. The issue can be looked at here. In my case, I just downgraded from 1.8.0 to 1.7.2 and for now it’s fine. May be will upgrade in the future.


Filed under AJAX, JQuery

AJAX and 403 Error

You would think people who have websites that get no more than a thousand page views and a few hundred unique visitors have a far more easier life than those admins of the likes of Google and Facebook. To the most part that’s true. But then, even small admins like us face issues for no fault of us.

I have exactly such a small website that has been working just fine and I hardly maintain it. But then, one fine day, I realized that the records in a table were not getting inserted. Initially I thought it may be related to the sqlite db getting too big or corrupt. But it was just fine. Then, I thought the error might be with the AJAX library that I use from Google’s jsapi and moved to the latest version of prototype.js library. Even that didn’t help.

After a bit of one of those pulling my head moments, searching on the web gave me a clue. The script that inserts data into this table has a parameter whose value is a URL. But apparently if you have mod_security installed, it has some rule called 10_asl_rules.conf that triggers a 403 Forbidden error. Who would know that, unless you end up in this type of a scenario? The hard part is, for the large companies their admins would know what changes are being made to their infrastructure (or atleast that’s how it should be). But for small website owners who just get a shared hosting from web hosting company, they have no control. And these web hosting companies don’t realize that it’s their responsibility to inform their customers of upcoming changes and warn them of the repercussions. This is the second time in less than 6 months that my web hosting provider has screwed up things for me. The previous screw up was related to making my domain to be some remote mail server based or something like that because my MX entries (which I wanted for inbound email) point to a Google Apps based servers. So, my outgoing emails that I generate from the website stopped getting delivered. After noticing that none of the registered users were confirming their registration for a few months, I had to dig deep and find out what was going on with the emails. The support guys, after a lot of back and forth, finally tell me that they did this change a few months back.

If you are working for a web hosting company or an executive of one, please take this as a sincere and serious advice that you shouldn’t be changing the configurations without informing your customers.

Leave a comment

Filed under AJAX, web hosting

Sprinkle more AJAX for usability study

Recently I have developed a website that has a rich user interaction on the client side. A lot of dynamic html, javascript, DOM manipulation and mashups with JSON. After all that, as days passed by and I notice people visiting to the website, I had no way of knowing what the users were doing. Or the using the system the way it’s intended? Are they even aware of how to use it?

In the meantime I introduced a new AJAX call to the system to record a particular end action as that’s important to me and then observed that people were eventually reaching that end action. That’s when I realized that, by sprinkling the AJAX calls at the appropriate places, it would be possible to get a lot more information about how such highly interactive and complex user interfaces on the website are being used by the end users.

Leave a comment

Filed under AJAX, Usability

aStore and AJAX

I am writing this article based on someone visiting my blog searching “amazon astore in ajax”. For those that are not aware what Amazon aStore is, it is a solution that allows Amazon’s affiliates to quickly build a store front based on their own set of products so that their visitors can benefit from the carefully hand-picked products relevant to the website. Whether this is executed to this spirit or not is a different point :).

The astore that people build resides on Amazon’s own web server. It is not possible to put it on your own website directly. You have to use the frame or iframe ui components to have your astore show up inline. So, this is perhaps what prompted some creative developer to think about “wait a minute, why not I use ajax and display the astore content directly inline without using the frames”? Well, sounds like a good idea. And there may as well be a solution, but first I want to talk about potential issues with this approach.

  1. AJAX driven content is not SEO friendly
  2. Even if the homepage of your astore is fetched using AJAX and displayed inline, what about further navigation within the store? Those URLs directly point to the Amazon astore website. But I think some extra javascript coding can easily make clicking those links go through the same AJAX process and load the content. I just wanted to list this anyway, so that you don’t forget this fact.
  3. Now, the bigger issue is, AJAX does not allow cross domain scripting for security reasons. So, since your website domain and astore’s domain are different, how can AJAX help?

So, I did a bit of research and identified two potential solutions, one of which is not exactly AJAX. The solutions are

  1. AJAX Cross Domain script that allows you to write cross domain AJAX. Don’t get so excited in thinking that some clever hacker found a way to beat the security restriction of AJAX. This script is a magic 🙂 in that, it creates the illusion that you are doing cross domain ajax, but in reality, you are not. The call is routed through your server.
  2. aStore Proxy The second solution is the astore proxy script that does the same thing like the above, but tailored to be for astore and not a generic AJAX cross domain solution. The underlying principle of this is the same, in that the astore content is retrieved on the server side, all the links are rewritten to point back to your own server so that when a user clicks one of the links within the astore, the request goes back to your server and not to amazon’s server.

So, you can user either of the above solutions. With the first one, there would be some additional code involved to make everything work but still has a drawback with respect to aStore SEO since the astore content is not part of your web pages but gets included on the fly using javascript. But with the second script, the search engine crawler would see your astore content within your web page and does not have to understand that additional content can be fetched using javascript. Remember, most (or perhaps all) search engines don’t execute javascript to figure out your final page structure. They just parse the content as is.

Leave a comment

Filed under AJAX, aStore

Inline/Embedded XML in HTML

Ajax is cool, but in scenarios where it’s not needed, there is no need to use it. For example, if there is some XML data that is being rendered on the UI using Javascript, if the XML data is static, then there is no need to first load the page and then use the XMLHTTPRequest object (or Prototype.js) to get the XML and then use it.

Instead, it’s possible to simply embed the XML into the HTML document itself. What’s the benefit of this? It simply avoids an extra round-trip to the server. However, doing this required a bit of research and the typical differences with Firefox and IE. So, here is what I had researched and did to make it work in both cases.

IE supports xml tag that can be used to embed XML into a HTML page. In Firefox, simply embed the entire content in the same xml tag. However, an extra piece of code is needed to make it work in Firefox.

The syntax is

<xml id='xmldata' style='display:none;'>
any piece of xml

The style=’display:none’ is needed in Firefox. Otherwise, any content within this tag is going to be displayed. Finally, in the code following javascript is required

var xml = document.getElementById(‘xmldata’);
if(xml.documentElement == null)
xml.documentElement = xml.firstChild; /* This is required for Firefox. Make sure there is no gap between the xml tag and the root node */

That’s it!


Filed under AJAX, javascript

innerHTML and SCRIPT tags

I have a requirement where I get some HTML snippet through Ajax request and then update a div area. So far so good. The HTML snippet needed to have some javascript (so that I could display a date as per the user’s timezone). That’s when the trouble started.

After a bit of research, came to the conclusion that

div.innerHTML = some-string-containing-script-tags;

doesn’t work. Some one mentioned about using <\/script> instead of </script> but that didn’t work for me though there was a reply to the suggestion that it worked! Then there is an interesting hack on how to achieve the same. While this is a cool hack, I didn’t wanted to do it.

So, by trail and error, in Firefox 2.0, it seemed to work by doing the following.

var div = document.createElement('div');
div.innerHTML = htmlFromAjaxResponse;
var children = div.childNodes;
actualDivToBeUpdated.innerHTML = "";
for(var i=0;i<children.length;i++)

This worked in Firefox 2.0. The script in the original response HTML did get executed. (note though not to use document.write in the script. Instead, you have to manipulate the DOM).

The same technique didn’t work in IE though.

Update: As per microsoft making a script tag marked with DEFER attribute makes it possible to execute script by setting it through innerHTML. I tried and it worked. However, I now have the problem that the DOM node that’s inserted using the innerHTML doesn’t seem to be available by the time the script is executing even though the script is placed after the dom node.

Update 2: Finally got it working on both Firefox and IE. The problem with the DOM manipulation mentioned above is, in case of IE, after marking the script to DEFER, it is executed for the DIV element whose innerHTML is set. Since I am creating the DIV brand new, it’s not yet within the DOM, so trying to use getElementById in the script from the document is causing the problem. So, I had to introduce a dummy DIV element in the initial document and then it worked. However, for Firefox, the dummy element idea doesn’t work. It has to be a new element to create the DOM. Since that DOM is copied to the actual node as per the code shown above, at that time the script gets executed fine. So, I ended up writing browser specific code, but finally it seems to work for both browsers.


Filed under AJAX, DHTML, javascript

Ajax.Request Returning 405 Http Response

Today I experienced the problem of 405 HTTP Response on a production server while that didn’t happen in the test instance. This happened when doing an Ajax request using prototype.js Ajax.Request. The request is to fetch some static html. After a bit of a struggle, I realized that the default method option of Ajax.Request is POST and if the server is not configured (I don’t know how) to treat POST as GET for static content, this issue can happen. So, adding method: “GET” to the options list solved the problem.


Filed under AJAX

The AJAX response: XML, HTML, or JSON?

This is the exact question asked at quirksmode blog. There were several responses to it each with their own experiences.

I just ended up reading it because I am in the same dilemma. Ofcourse, for me it’s more of XML vs HTML. JSON is not one of the choices for my application. I initially started my ajax response as a html response but it had to evolve a bit more. Let me first explain what my requirement is. I have a bunch of markers (like on Google maps) and when the mouse is on top of a marker, I have to show the details about that marker. So, I used Ajax to do this. When the mouse is on a marker, I get the details related to only that marker. For this I used a html response and on success, just took the transport.responseText and put it into a div element.

Now, I want to support the case where I get the details of all the markers with a single response. In this case, on the client side I have to take the response, and maintain a hashmap of the details for each marker (which has a unique id). One of my preferences is to not generate the html on the client side. So, the server already formats the html. So, I had the choice of embedding the html of each marker within the xml response. But if I did this, I have to convert the dom representation of the html to a string representation which is cumbersome. So, I ended up capturing the html as cdata. The good thing with this approach is, the outer shell is an xml, but each cdata is a html string. Further, my already existing html generation code on the server side didn’t needed a fix as it wasn’t generating proper xhtml and had the html been represented as xml, I would have ended up with errors. So, the cdata representation of html saved both server-side and client-side coding.

1 Comment

Filed under AJAX

State, Navigation & Performance

Web Applications development is all about managing the state and navigation. And for those few lucky sites that have high traffic (like, performance also matters. Two days back I happened to be looking at a portal application that was trying to display reports in real time. Since a portal typically has multiple portlets in it each one showing a real-time report, the way that particular portal application was designed was to initially show loading icon till the portlet page is loaded and then display the page. One good thing with this approach, as opposed to sequentially building the entire page within a single request is that user can start looking at the content as soon as it’s queried and sent to the client. The downside is that there will be multiple client requests to serve each page, one per each portlet, that would be expensive.

Now, this particular portal page I happened to look at has drill-down pages for each report and a group of people are constantly looking at the report and the drill-down. The drill-down is in a separate page, so there is a lot of navigation going back and forth. And each time the user clicks from the drill-down page to the main portal page, the portal page starts rendering all the portlets in real time. This definitely didn’t look promising as it was taking a lot of time for the page to render and consuming a lot of the entire group’s time.

Now, I have recently been experimenting with GreyBox. What this does is, it allows you to open up a detailed page in a embedded window without leaving the current page. When the user clicks on a link, it greys out the original page, and puts a new box with the target link. Hence the name, GreyBox, I would assume. The good thing with this approach is, since one can look at the details, without leaving the current page, in a scenario like a Portal, it would be extremely useful.

I think, overall, with AJAX, DHTML and JavaScript, a lot of server side load can be reduced by carefully designing the navigation using widgets like GreyBox.

Leave a comment

Filed under AJAX, DHTML, GreyBox, performance, portal, web development