404 Error With AJAX Postback

Jul 9, 2010 at 6:02 PM

I have created a simple page in a portal-enabled web site which has an AJAX Script Manager and an Update Panel that contains a Button and a Label control. When the button is clicked, a server side event is triggered which updates the label's text to the current date/time. 
If I click the button two times in a row, I receive an AJAX error: "Line: 868 Error: Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 404"
The fiddler trace shows that the AJAX postback URL has the pageid query string parameter appended to it twice. 
http://jeffr:4545/Test.aspx?pageid=bed190c8-818b-df11-9344-00155d021604&pageid=bed190c8-818b-df11-9344-00155d021604
This duplicated pageid query string parameter appears to be the issue. Has anyone else experienced this? Have I mis-configured something in my portal web site? I am not familiar enough with the guts of the URL rewriting that the portal libraries are performing to know where this extra pageid query parameter may be coming from.... 
Thanks!
Jeff

ASPX

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Test.aspx.cs" Inherits="Portal.Pages.Test" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:ScriptManager ID="ScriptManager1" runat="server">
        </asp:ScriptManager>
    <asp:UpdatePanel ID="UpdatePanel1" runat="server">
        <ContentTemplate>
            <asp:Button ID="Button1" runat="server" Text="What Time Is It?" OnClick="Unnamed1_Click" />
            <br />
            <asp:Label ID="Label1" runat="server" Text="0:00:0000"></asp:Label>
        </ContentTemplate>
    </asp:UpdatePanel>
    </div>
    </form>
</body>
</html>

ASPX.CS
protected void Unnamed1_Click(object sender, EventArgs e)
{
    Label1.Text = DateTime.Now.ToString();
}


Jul 12, 2010 at 8:42 PM
Edited Jul 13, 2010 at 12:43 PM

I was able to confirm that this issue is caused by the module Microsoft.Xrm.Portal.Web.SiteContextModule which performs the URL rewriting for the portal engine. I did not dig in too far to determine a root cause, so I cannot say with certainty whether this is a bug in the HttpModule or an issue that is specific to my environment. In case anyone else runs into the issue, I ended up addressing it by using a work-around that adds some simple URL rewriting to the BeginRequest event in the Global.asax file. This code reviews the query string and removes any duplication that exists on the query string for the pageid key. The code I used has been moderately tested and I have included it below for informational purposes. If you wish to utilize this code, please do your own testing as I have only attempted to accommodate this specific scenario and have probably not addressed issues that may be specific to your environment

protected void Application_BeginRequest(object sender, EventArgs e)
{
    // check for multiple query string values for a single pageid key
    if (Request.QueryString["pageid"] != null && Request.QueryString["pageid"].Contains(','))
    {
        // get the pageid value
        string[] pageIds = Request.QueryString["pageid"].Split(',');
        // identify the query string value to remove
        string pageIdQueryValue = string.Format("pageid={0}&", pageIds[0]);
        string queryString = Request.Url.Query;
        // start loop at 1 to leave a single instance of the query string value present
        for (int i = 1; i < pageIds.Length; i++)
        {
            queryString = queryString.Replace(pageIdQueryValue,string.Empty);
        }
        // rewrite path with modified query string
        Context.RewritePath(Request.Url.AbsolutePath + queryString);
    }
}

 

Jeff

Aug 18, 2010 at 5:43 PM
Edited Aug 18, 2010 at 5:43 PM
This work-around appeared to resolve the problem for a while. Recently, however, I deployed the application to another IIS 7.5 web server, and ran into the exact same issue that I was previously having. Two IIS 7.5 servers with the same basic configuration seem to be behaving differently. Has anyone else experienced this when using AJAX with the portal DLL's? Is there a way to fix this rewrite issue once and for all that isn't quite as hacky as this? Jeff
Aug 19, 2010 at 1:01 AM

My team was able to reproduce your issue if they removed the form.browser file from the App_Browsers folder.  This adapter automatically fixes the issues with asp.net url rewriting and using web forms.  I would consider this file required for the portal accelerator.  Have you modified the portal or are adapting it to meet your own needs?  And if you have, did you copy the form.browser file into your project?  I do not recommend that you use the global.asax approach documented earlier in this thread.

For more information about this technique, I highly recommend reading Scott Guthrie's blog article: http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx

Thanks,
Shan McArthur
www.shanmcarthur.net

Aug 19, 2010 at 1:31 PM

Hey Shan,

I do have the Form.browser file in the App_Browsers folder on the project, and (assuming I have set it up correctly) the Xrm portal framework should have full control over the URL’s that are used in this site (the global.asax code is currently commented out). I have noticed, however, that I do not see the FormRewriteControlAdaptor that is referenced in the Form.browser file being called in any of the tracing (both for requests which work, and the ones that do not). Is this normal?

This morning I also discovered that using the ASP.NET Development Server to run the application appears to work fine, multiple AJAX requests execute properly, and there appears to be no issue with the URL. It seems that I have the issue only when running the site under IIS 7.5 (which is how I normally run it locally and on our dev server). I reviewed the documentation again, and I don’t see anything in particular that should be configured for IIS 7.5, have I missed something here? Is there something I ought to do on the IIS 7.5 web server to ensure that the Form.browser is respected and utilized?

Jeff

Aug 19, 2010 at 2:08 PM

Hmm.  I will ask my team to document the settings that they were testing to see if there is something else amiss.  I am surprised it is working in Cassini but not in IIS.  We do all of our development using IIS 7.5.  Cassini (the asp.net development server) has some problems that do not properly emulate IIS 7 and most of the url rewriting doesn't work properly because of that.  Running the site in full-blown IIS 7.5 is preferred.  One thing I would like to confirm - are you running your app pool in integrated mode, or classic mode?  It should be in integrated mode.  You won't see any tracing of the FormRewriteControlAdapter as it does not currently output anything to the trace.

Shan

Aug 19, 2010 at 2:31 PM

The site has its own application pool, runing .NET 4.0, in Integrated pipeline mode.

After doing futher testing, I have noticed that this seems to only affect the published version of the site. If I run an IIS site against the project folder, the site works fine. If I run the IIS site from the compiled/published project, it exhibits the issue. This behavior is consistant on my machine, and on our development web server. I am using Visual Studio 2010 to publish with the File System method to a folder that the IIS is pointed at with the Delete all existing files prior to publish option selected.

Jeff

Dec 1, 2010 at 8:43 PM

Any word on the issue mentioned above Shan?

We are trying to go live with a portal site, but are unable to publish the compiled version of the portal. I'm getting a ViewState error (which doesn't seem to have anything to do with ViewState as disabling verification and encryption does not resolve the issue), and the request URL's all have an excess of PageId's concatenated on.

For example:

Original URL: http://jeffr/sign-in?ReturnUrl=%2f

URL after first AJAX call on page: http://jeffr/SignIn.aspx?pageid=7873186f-f465-45f1-ac3e-eb12094f15ac&ReturnUrl=%2f

 

URL after second AJAX call on page (this is where things begin erroring out): http://jeffr/SignIn.aspx?pageid=7873186f-f465-45f1-ac3e-eb12094f15ac&pageid=7873186f-f465-45f1-ac3e-eb12094f15ac&ReturnUrl=%2f

 

The uncompiled version of the site works fine, and there is no issue with the pageid's, but I have no idea why. Microsoft does not seem to offer any sort of formal support for the accelerators, are there any support options for the portal other than this forum?

 

Jeff