This seems iffy to me. I looked at the JSON formatter and it will never throw anything. If you don't have a body to return it shouldn't try to format it IMO, maybe that's a better fix?

None of the other formatters raise an error.. I'm not sure why the XML formatter does.

This issue has been aggravating me for a while as OPTIONS requests raise 500 errors because the formatter tries to format an empty string. This raising of an exception was originally added in commit 11576c8

My fix, allows the behavior created in that commit to remain while allowing OPTIONS requests to properly work.

I don't think this is the right fix, more like a hack, so I can't merge it. We need definite behavior for empty strings and the XML formatter, it needs to be understood and unambiguous.

With JSON it's clear: you can return an empty string and you can return a nil object.

1.9.3-p551 :002 > ''.to_json
 => "\"\"" 
1.9.3-p551 :003 > nil.to_json
 => "null" 

What should it be in XML?

The OPTIONS request should have no body.. So what you define for the XML formatter for GET/POST/PUT/,etc.. need not apply to the OPTIONS request. the only reason this issue is happening is that browsers (testing Firefox) will sent a standard accept header which included xml but not JSON, so grape jumps to XML as the response type.

I agree with you, but it's beyond the point. Are you still saying this is the proposed fix?

This fixes the issue by leaving the XML handling alone for non-OPTIONS requests. and fixes the OPTIONS now, which shouldn't have any body.

I've adjusted my fix slightly so that it only applies the fix if there is no body for OPTIONS. That way if someone overrides the OPTIONS request and returns a body (reserved for future use according to the RFC) then it'll work correctly.

Sorry, but a fix that checks the verb used in the request in a formatter is definitely not something I can take into Grape. I understand it fixes your particular scenario, but it's not the right solution. There's at least another scenario where the same problem surfaces in a totally different way.

I am going to close this without merging. Lets move this into #1162 and discuss what the right solution would be? I am here to help.

Closed via #1190