This project is archived and is in readonly mode.

#814 ✓invalid

Request's onFailure called with response.text as null

Reported by elado | December 20th, 2009 @ 12:15 AM | in 1.3.0 rc2 (closed)

The server can return a different status than 200, like 401, with an error message like "Access denied", but a Request won't be able to handle this text because it nullifies the values:

onStateChange: function(){
    this.response = {text: null, xml: null};

The only way to access this text is thru this.xhr.responseText.
I suggest that the text will be there like in onSuccess.

Comments and changes to this ticket

  • fakedarren

    fakedarren February 8th, 2010 @ 07:37 PM

    • State changed from “new” to “hold”
    • Assigned user set to “fakedarren”
    • Milestone changed from 2.0 to 1.3.0 rc2

    I've got to talk to the other devs whether we expect to support 'odd' statuses. Will update soon.

  • fakedarren

    fakedarren February 15th, 2010 @ 10:33 PM

    • State changed from “hold” to “invalid”

    Sorry, we won't 'fix' this - you have the onException event too.

    If a HTTP request fails, there is no response from the server so don't see how we can send you response text. The HTTP request has failed.

  • elado

    elado February 15th, 2010 @ 10:44 PM

    Actually you can send HTTP response with any content and any status you'd like, so it is relevant IMO.

    onException happens only on 'setRequestHeader' thrown error.


  • fakedarren

    fakedarren February 15th, 2010 @ 11:01 PM

    Feel free to submit a pull request via github.

    However it is my opinion that a Request object either works ('success') or fails ('failure'). As you point out this content is still available through this.xhr.responseText. But we won't support this onSuccess, as, well, it's not been a success.

  • Sebastian Markbåge

    Sebastian Markbåge February 16th, 2010 @ 10:03 AM

    I do agree that responseText should be provided if it fails. It allows you to pass error messages to the client through RESTful services. It can be null if it's a failure that doesn't have a response.

    Not having it, encourages the use of error messages being passed through the "200" range. That breaks the usefulness of these services as proper RESTful HTTP services.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Shared Ticket Bins