Exception thrown for empty 204 HTTP response

[derekcicerone-zz]

I just upgraded to AngularJS 1.3.0-rc5 and I'm seeing an exception when $http attempts to handle a REST call response which returns a 204 status code with an empty entity (basically an empty string):

SyntaxError: Unexpected end of input
    at Object.parse (native)
    at fromJson (https://localhost:3443/bower_components/angular/angular.js:1103:14)
    at defaultHttpResponseTransform (https://localhost:3443/bower_components/angular/angular.js:8319:18)
    at https://localhost:3443/bower_components/angular/angular.js:8264:12
    at forEach (https://localhost:3443/bower_components/angular/angular.js:335:20)
    at transformData (https://localhost:3443/bower_components/angular/angular.js:8263:3)
    at transformResponse (https://localhost:3443/bower_components/angular/angular.js:8953:17)
    at processQueue (https://localhost:3443/bower_components/angular/angular.js:12642:27)
    at https://localhost:3443/bower_components/angular/angular.js:12658:27
    at Scope.$get.Scope.$eval (https://localhost:3443/bower_components/angular/angular.js:13851:28) 

It looks like the response handling logic was changed so that setting a content type of "application/json" now properly attempts to parse the response as JSON every time. However, if the response is empty the JSON.parse() call fails. I wonder if perhaps a return code of 204 might need some special handling which interprets the returned data as undefined or null and does not attempt to parse the response entity.

[derekcicerone-zz]

Oh, I should mention that the HTTP response was serialized by Jersey (https://jersey.java.net/). Its fairly popular in the Java community so I'm guessing others will hit this once they upgrade AngularJS.

[caitp]

Empty string isn't really valid JSON, is it? In any case we could test that the string it's non-empty before parsing?

[derekcicerone-zz]

Here is the bug on Jersey that talks about this:
https://java.net/jira/browse/JERSEY-77

The crux of the argument seems to be this part:

RFC2616 (section14.13) states that "Any Content-Length greater than or equal to zero is a valid value". Similarly, 
section 4.3 states that "All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT 
include a message-body. All other responses do include a message-body, although it MAY be of zero length."

I believe testing for an empty string would work but my read of this is that the status code should be looked at instead since its more explicit.

[caitp]

Rfc2616 is entirely unrelated to JSON---basically we shouldn't have a content-type with application/json if the text is empty. However, we do need to deal with this for HEAD requests at the very least

[IgorMinar]

HTTP 204 means No Content. It's similar to HTTP HEAD we should deal with this.

This will be fixed by #9529