I\'m tearing my hair out over this one, so bear with me (it\'s a long post).
Here is another shot. I'll leave my original attempt incase that solution helps someone else.
To fire the error condidition for the $.ajax call you will need an error code in your response
protected virtual void ApplyHttpResponseSettings(ref Message fault, System.Net.HttpStatusCode statusCode, string statusDescription)
{
var httpResponse = new HttpResponseMessageProperty()
{
//I Think this could be your problem, if this is not an error code
//The error condition will not fire
//StatusCode = statusCode,
//StatusDescription = statusDescription
//Try forcing an error code
StatusCode = System.Net.HttpStatusCode.InternalServerError;
};
httpResponse.Headers[HttpResponseHeader.ContentType] = "application/json";
httpResponse.Headers["jsonerror"] = "true";
fault.Properties.Add(HttpResponseMessageProperty.Name, httpResponse);
}
Heres hoping my second attmpt is more useful to you!
I had the same symptoms with a different scenario so this may or may not help.
Here is a breif summary of what I was doing and our solution:
I was posting to a REST implementation of a WCF service that we host from a classic ASP page. I found I had to set the input as a stream and read from that, disposing of the stream when done. I beleive it was at this point I was getting the 202 response with text of "success" as you have described. I discovered that by not disposing of the stream I was getting the response I was expecting for error conditions.
Here is a summary of the final code:
[WebHelp(Comment="Expects the following parameters in the post data:title ...etc")]
public int SaveBook(Stream stream)
{
NameValueCollection qString;
StreamReader sr = null;
string s;
try
{
/**************************************************************************************
* DO NOT CALL DISPOSE ON THE STREAMREADER OR STREAM *
* THIS WILL CAUSE THE ERROR HANDLER TO RETURN A PAGE STATUS OF 202 WITH NO CONTENT *
* IF THERE IS AN ERROR *
* ***********************************************************************************/
sr = new StreamReader(stream);
s = sr.ReadToEnd();
qString = HttpUtility.ParseQueryString(s);
string title = qString["title"];
//Do what we need
//Then Return something
int retRecieptNum = UtilitiesController.SubmitClientEntryRequest(entryReq);
return retRecieptNum;
}
catch (Exception ex)
{
throw new WebProtocolException(System.Net.HttpStatusCode.Forbidden, ex.Message, this.GetExceptionElement(true, "BookRequest", ex.Message), false, ex);
}
finally
{
}
}
Hopefully this is some help to you, maybe try using a stream and see how that goes.
Have you looked at JSON.NET? I was using it to convert objects in c# to JSON friendly strings then passing it back across the wire to my client where I parsed it into a JSON object. In the end I got rid of it and went to JSON2 for stringify. Here is my ajax call I use:
function callScriptMethod(url, jsonObject, callback, async) {
callback = callback || function () { };
async = (async == null || async);
$.ajax({
type: 'POST',
contentType: 'application/json; charset=utf-8',
url: url,
data: JSON.stringify(jsonObject),
dataType: 'json',
async: async,
success: function (jsonResult) {
if ('d' in jsonResult)
callback(jsonResult.d);
else
callback(jsonResult);
},
error: function () {
alert("Error calling '" + url + "' " + JSON.stringify(jsonObject));
callback([]);
}
});
}
I'm not familiar with ASP or WCF, but I am quite familiar with jQuery. The one thing that sticks out in my mind about your question is that your service is returning 202 Success
when an exception is thrown. jQuery chooses which callback to call (success
or error
) based on the HTTP status code that is returned from the server. 202
is considered a successful response, and therefor jQuery will call success
. If you want to have jQuery call the error
callback, you need to make your service return a 40x
or 50x
status code. Consult http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html for a list of HTTP status codes.
I had a similar problem sort of with WCF and using ASP.NET compatibility as I integrate MVC and WCF in my solution. What I would do is throw a WebFaultException then check the Status of the response at the receiving end (either java or other .NET client). Your custom error could then throw that if the WebOperationContext.Current is not null. You are probably aware of this already but just thought I would throw it out there.
throw new WebFaultException(HttpStatusCode.BadRequest);