6

A few colleagues and I have a problem whereby the response from an ajax call returns some unexpected content. Rather than getting a simple JSON object back with various properties, the value of result.responseText is the HTML markup of a generic 406 status error page, saying the MIME type is not accepted by the browser.

The call is made like so:

$.ajax({
    url: '/promociones/cincogratis/canjear-codigo-promocional',
    type: this.method,
    data: $(this).serialize(),
    success: function (result) {
           $('.promotion_banner .loader').hide();
           $('.promotion_banner').html(result);
    },
    error: function (result) {
           var obj = result.responseText;
           if (obj.isRedirect) {
                   document.location = obj.redirectUrl;  
           }
           else {
                   $('.promotion_banner .loader').hide();
                   $(".error-wrapper").removeClass("hidden");                           
                   var generic_error = document.getElementById('generic_error').value;
                   $(".error-wrapper p").html(generic_error);
           }
    },
    beforeSend: function() {
           $('.promotion_banner .loader').show();
    }
});

The controller response to the call is like so:

Response.StatusCode = (int)HttpStatusCode.NotAcceptable; // 406
return Json(new { errorMessage = LocalErrorMessages.Website_Promotions_FreeFiver_General_Problem, isRedirect = false } );

We would expect result.responseText to contain key values for errorMessage and isRedirect, but they’re not there.

It’s worth pointing out that this code is multi-tenanted, shared by the current application and another one, where it works absolutely fine.

We’ve tried:
- Configuring IIS to show detailed error responses rather than a custom page for more detail – gives us nothing extra towards solving the problem.
- Allowing all response content types to the call
- Changing the culture of our site (which is currently es-ES)
- Various web.config tweaks

Has anyone ever had this problem?

dev'd
  • 469
  • 1
  • 4
  • 12
  • `406` is meant to be used if the the various `Accept` headers sent by the client are not supported by the server. Is this what your error response really means? I don't think and HTTP error is the right approach; perhaps you should return a `200`, and the client would inspect the response to know if it was an error (or maybe there is a more correct status code). – Jacob May 01 '13 at 18:58
  • According to this answer, `403` may be a better choice, and perhaps it would preserve your JSON: http://stackoverflow.com/a/3290369/119549 – Jacob May 01 '13 at 19:03
  • Thanks Jacob. HTTP is an application level protocol so we're using 4xx as a way to tell the the browser that there has been a business error. What is unusual is that our 406 response returned by the server is part of a core codebase (each of our applications are consuming the same code here), and we're only experiencing this problem for one of the applications. – dev'd May 02 '13 at 09:39
  • I attempted the 403 as per your suggestion but the problem persists. – dev'd May 02 '13 at 11:36

1 Answers1

0

Simplify your request. Maybe something like:

$.ajax({
    url: '/promociones/cincogratis/canjear-codigo-promocional',
    type: 'GET',
    data: {foo:'bar', one:'two'},
    dataType: 'json',
    success: function (result) {
           console.dir(result);
    },
    error: function (xhr) {
           console.dir(xhr)
    }
});

And post the response from the server. This kind of error seems a request problem rather than server configuration issue

Alwin Kesler
  • 1,450
  • 1
  • 20
  • 41
  • I think the question is why the JSON contained in the error isn't showing up, not why the error is received (it's expected to get a 406) – Jacob May 01 '13 at 18:48
  • That's why I set `dataType:'json'` in the parameters (maybe thinking that jQuery is having problems interpreting the header's accept – Alwin Kesler May 01 '13 at 18:55
  • The 406 error status is something explicitly sent in the OP's code. – Jacob May 01 '13 at 18:59
  • Thanks Alwin. We've attempted to set the dataType and accepts properties of the call, but they don't seem to have any effect unfortunately – dev'd May 02 '13 at 11:37