I’ve been developing a web application on my local machine for several days using Visual Studio 2010. Last night I deployed my application to IIS 7 and disappointedly stumbled upon a major traffic jam. The problem is with error handling in the Ajax request. For starters, I have some edit screens that work on ajax request. Here's what the ajax portion of the Ajax edit screen looks like.
@using (Ajax.BeginForm("_CityEdit", null, new AjaxOptions { HttpMethod = "Post", UpdateTargetId = "content", LoadingElementId="imgSaveLoading", OnFailure="onError", OnSuccess = "onSuccess" }, new { id = "frmCity" })) { <img id="imgSaveLoading" alt="loading" src="@Url.Content("~/Content/Telerik/Vista/loading.gif")" class="ajax-loader-user" /> <div class="content" id="content"> @{Html.RenderPartial("_CityEdit");} </div> <!-- Some Other code here --> }
I relied on the onError callback above Ajax.BeginForm (). Therefore, in my controller whenever I wanted to display an error for the user (model error or any other error), I simply optimize the response of the 500 Server (Internal Server Error), hoping that this will lead to the "OnError" Ajax.BeginForm () handler . Here is a snippet of how I did this in my controller.
[HttpPost] public ActionResult _CityEdit(CityViewModel viewModel) { city = cityManager.FindCity(viewModel.City.Id, false); // Validate Model here if (!TryUpdateModel(city, "City")) { Response.StatusCode = 500; return PartialView("_CityEdit", viewModel); }
As you can see from the above code, I returned PartialView, and if it contains model errors, they will automatically appear on the Ajax editing screen. Then in JavaScript "OnError" I just replace the associated PartialView div returned by the controller, something like this.
function onError(xhr) { $('#content').html(xhr.responseText); }
All this worked fine on my development machine. When I deployed my application to IIS 7 and accessed it from a Windows XP window (with IE 8 or Chrome), instead of PartialView, the browsers simply displayed the "500 Internal Server Error" screen by default. Therefore, I have a few doubts that made me not sleep well last night.
Is the approach that I used to edit Ajax reasonable. If not for what could have been a different way, I could have handled Ajax Editing (with the ability to display model errors).
Since I have been developing these modules for several days now and put a lot of effort into it, are there any problems to get it working on the XP box. Basically, it would be ideal if I could somehow prevent the browser from displaying its default screen of “500 Internal Server Error”.
This approach works in Windows 7 because I have IIS 7 installed on the same Windows 7 machine that I use to go to the site, or simply that it works well with windows 7.
If any other suggestions please continue.
Edit: I found a workaround for my problem. Thus, this means that there are no answers to 2 and 3. Basically, the following entry in web.config prevents the browser from showing the default browser pages for the website.
<system.webServer> <httpErrors errorMode="Detailed"/> </system.webServer>
But that still leaves my first doubt. Did I use a reasonable approach to editing Ajax?
I checked the answer with the violinist, and it was IIS who sent the default error page for the 500 server error. Therefore, it must be configured to return a "verbose" response. We can do this using the IIS Manager. Another option I used is to define it at the application level in the web.config application file.
However, I am again experiencing a dilemma: whether to go with this approach or to recycle my entire application. There is a problem: if in fact some module does not work with 500 Internal Server, my code opens in the browser, as the errorMode parameter is set to "Details". So I need to somehow provide my custom answer when I set the response error code to 500, and if any other part of the application fails (I'm not the one that sets the status code 500), then I should send the default error page instead of exposing my code through a "verbose" answer. Any help please.
Regards, NIrvan.