Posted By Mobeen Anwar on Jun 21, 2010 | 2 comments

Today I spent a large part of the day battling with a very strange problem. My infrastructure team had set up and enabled Akamai on a newly deployed Telligent Community site. This had an unintended effect of causing parts of the site to break in a couple of significant ways.

Firstly, the site began to throw Object expected JavaScript errors in Internet Explorer 8 and __doPostBack is not defined JavaScript errors in Firefox 3.6.3 when I attempted any action that makes use of postbacks in .NET controls. These issues were not present before we attempted to render the site through the Akamai network.

Secondly, some code changed in the source of the page. Before Akamai was enabled the source contained all the code that was needed for postbacks:

<form name="aspnetForm" method="post" action="/login.aspx" id="aspnetForm" enctype="multipart/form-data" >
<div>
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/{ViewStateData}" />
</div>

<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['aspnetForm'];
if (!theForm) {
    theForm = document.aspnetForm;
}
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;
        theForm.submit();
    }
}
//]]>
</script>

Akamai, on the other hand, removed the __doPostBack() function and the required __EVENTTARGET and __EVENTARGUMENT hidden input fields when it rendered the code.

<form name="aspnetForm" method="post" action="/login.aspx" id="aspnetForm" enctype="multipart/form-data" >
<div>
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/{ViewStateData}" />
</div>

This meant that any postback operations on the site no longer worked.

After some investigation it turned out that the reason for this is because Akamai was changing the value for the user-agent to the string Akamai Edge, regardless of the browser that was being used to send the requests. This user-agent was clearly visible in the Internet Information Server log files.

As a further test, the problem could be re-created by using the Tamper Data add-on in FireFox against the non-protected site (i.e. by modifying my hosts file to point to a single box in the web farm and not getting the content via Akamai). With this scenario I was able to change the user-agent of the requests to Akamai Edge and again see the above manifestations of this issue.

The reason this was occuring was because the Akamai feature Edge Server Identification was enabled. The resolution of this problem was simply to disable this feature.

This requires for an authorised Akamai user to enter into the Akamai Edgecontrol system and create a new configuration (based on a previous version) and in the Edge Services – General section to ensure that the Enable Edge Server Identification checkbox is unchecked.

On activation of this new configuration (which took several hours) this particular issue was resolved.

@MobeenAnwar