Invalid rack response.

[tonobo]

Please see here puma/puma#1208

[namusyaka]

@dopykuh Could you provide minimal failing project as github repository?

[tonobo]

These 2 lines will produce my exception dab3c09#diff-e9e8424a5238d48301e313d8fe285697

[dblock]

I wouldn't be so sure that this is a grape bug. It looks like the response is a hash that is not being formatted into a string. Which content type is here? What is the response from the DELETE (implemented by the user)?

[tonobo]

Request on v.18.0

curl localhost:9000/api/v1/ldap?mac=00%3A50%3A56%3A00%3A00%3A00 -X DELETE -i; echo
HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 96

{"ip":"10.10.10.1","mac":"00:50:56:00:00:00","gateway":"10.10.10.10","netmask":"255.255.255.224"}

Request on v.19.0

curl localhost:9000/api/v1/ldap?mac=00%3A50%3A56%3A00%3A00%3A00 -X DELETE -i; echo
HTTP/1.1 500 Internal Server Error

[tonobo]

The issue could also been appeared earlier, but it looks like an grape bug. You only setup a default right now, but response_body shouldn't be served as hash or not?

[dblock]

This is a little more complicated. In 0.19.0 we made the server return 204 on a DELETE, then in 0.19.1 we fixed #1550 to return 200 when there's no content. That's ultimately what's causing this, but it's not necessarily a bug.

So what you need to find out is why isn't your JSON formatter invoked on a DELETE. Wrong content type? Is JSON not the default formatter? I would definitely try explicitly 0.19.1, then HEAD, then I would dig through the code - maybe you have a custom formatter or something else in the way?

As a workaround you can probably add in status 200 in your API response and the problem will go away.

[tonobo]

Ok, i'll check this tomorrow. I also tested head and 019.1, but how is it possible that the formatters are completly skipped, it would be nice if a fallback will raise or log a warning or sth. else. I'll try to find out where it comes from, i am able to reproduce them within my environment. ;)

[dblock]

I am just speculating from the top of my head. Build a simple repro, maybe even a spec.

[tonobo]

I am unable to reproduce it out of my app environments. Currently i don't know why...
Alternativly i switch my job to gardener. ;)

[dblock]

[LeFnord]

Hi @dopykuh … how did you achieve this behavior?

curl localhost:9000/api/v1/ldap?mac=00%3A50%3A56%3A00%3A00%3A00 -X DELETE -i; echo
HTTP/1.1 201 Created

you make a DELETE request, but your response assumes, you made a POST request

for further investigating, I suggest to pry into a rescue from all block →

rescue_from :all do |error|
  require 'pry'; binding.pry
end

to catch the errors and see what is really happened

@dblock one minor correction, in 0.19.0 status 204 was introduced as default for delete requests with an empty body, in 0.19.1, it was completed, to return 200 if the response did have a body 😉

[tonobo]

@LeFnord sorry, wrong output posted.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 163

json body...

[tonobo]

@LeFnord its also not possible to rescue there because the exception will be raised within puma response handler due to unformatted response. Grape possibly skips the formatters so the impact is only visible later.

[tonobo]

The exception doesn't occur by manually setting status 200

[tonobo]

v0.19.0...v0.19.1#diff-e9e8424a5238d48301e313d8fe285697R133

It looks like the body isn't already detected here, but will be served later. So it returned a 204 with content, which will trigger the issue?

[dblock]

You narrowed down the problem, 204 means no content, so you should not have content with a 204. Now find how this happens.

[tonobo]

@dblock I'll take a look at monday. Could you give some tips, or do you have any ideas where the issue possibly come from? I don't know anything about your framework structure and debugging large dsl's are not as easy. :D

[dblock]

I don't think I have much more useful info to add ;( Let us know what you find! If you put a repro up obviously it would be helpful.

[tonobo]

I tried, but i am unable to reproduce them. Don't know why ...

[dblock]

Fixed in #1579.