Defect #11388

Updating a version through rest API returns invalid JSON

Added by Daan Broekhof over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:REST API
Target version:2.1.0
Resolution:Fixed Affected version:2.0.3

Description

After PUTing a successful version update API request to /versions/1234.json, a response body consisting of one space is returned, while it declares itself to be 'Content-Type: application/json'.

One space (" ") is not valid JSON, so a client interpreting the response according to the content-type header will issue an error.

(reported before in #9598, but does not mention content-type clash)


Related issues

Related to Redmine - Defect #9598: JSON REST API : PUT returns one space character Closed 2011-11-18
Duplicated by Redmine - Defect #11491: JSON / XML format : delete / put dont send any data Closed

Associated revisions

Revision 9975
Added by Jean-Philippe Lang over 5 years ago

Fixed that 200 API responses have a body containing one space (#11388).

History

#1 Updated by Etienne Massip over 5 years ago

  • Category set to REST API

#2 Updated by Etienne Massip over 5 years ago

  • Target version set to Candidate for next minor release

#3 Updated by Jean-Philippe Lang over 5 years ago

  • Target version changed from Candidate for next minor release to Candidate for next major release

Lets define the expected behaviour first.

#4 Updated by Jean-Philippe Lang over 5 years ago

A more appropriate response should be a 204 response but I guess it could break some API clients. So I propose to respond with a 200 and an empty body. Should we keep the Content-Type as it is now?

#5 Updated by Etienne Massip over 5 years ago

There has been a related commit in RoR (original LH ticket) to return an empty object (because setting Content-Type and no body makes no sense either I guess).

After discussion, it was eventually overrided by a new commit setting the response code to 204 and setting the body back to an single space.

I would do the way Rails do.

Edit: not an empty string, a single space.

#6 Updated by Jean-Philippe Lang over 5 years ago

The default Rails behaviour is now a 204 No Content with a non-empty body, really?

#7 Updated by Etienne Massip over 5 years ago

Jean-Philippe Lang wrote:

The default Rails behaviour is now a 204 No Content with a non-empty body, really?

Well, I did not test but that's what the code and commit say :D

...
assert_equal 204, @response.status
assert_equal " ", @response.body
...

#8 Updated by Jean-Philippe Lang over 5 years ago

I have made a few tests with JQuery. It gives an error when responding with a one space response body indeed. But it seems to work fine with a 200 response and an empty body, even if the response Content-Type is set to text/json. It gives no error and returns null.

So I propose to just change the "one space" response body to an empty body.

#9 Updated by Etienne Massip over 5 years ago

Did you try with a 204 and a single space?

#10 Updated by Jean-Philippe Lang over 5 years ago

No, but I really don't want to change the API behaviour in this way and break compatibility.

#11 Updated by Jean-Philippe Lang over 5 years ago

Etienne Massip wrote:

Did you try with a 204 and a single space?

It seems to behave just like with an empty 200 response.

#12 Updated by Etienne Massip over 5 years ago

FTR, there exists a jQuery bug which has been closed.

Quote : An example of this is the 204 No Content status. The HTTP specification is unclear as to the inclusion of content-type. It does not forbid including it at any rate. But it does forbid the inclusion of a message-body.

#13 Updated by Etienne Massip over 5 years ago

Jean-Philippe Lang wrote:

So I propose to just change the "one space" response body to an empty body.

Agreed.

#14 Updated by Jean-Philippe Lang over 5 years ago

  • Status changed from New to Resolved
  • Assignee set to Jean-Philippe Lang
  • Target version changed from Candidate for next major release to 2.0.4
  • Resolution set to Fixed

#15 Updated by Jean-Philippe Lang over 5 years ago

  • Status changed from Resolved to Closed
  • Target version changed from 2.0.4 to 2.1.0

No feedback about the change, it will wait for 2.1.0.

Also available in: Atom PDF