Reputation: 43
I develop API in Rails 4.0 and try to test it using Postman. I constantly get 500 status code as an answer for POST request with empty body.
It doesn't matter if I use correct url or not. It seems it's impossible to process empty POST request in rails. When I try it with PUT, DELETE and so on there is no problem.
Request:
POST /whatever HTTP/1.1
Host: localhost:3000
Cache-Control: no-cache
Postman-Token: c479c760-214d-93f0-3a49-2a11c95758f4
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Response headers:
Connection
Options that are desired for the connection
close
Content-Length
The length of the response body in octets (8-bit bytes)
296
Content-Type
The mime type of this content
text/html; charset=ISO-8859-1
Date → Fri, 22 May 2015 13:57:57 GMT
Server → WEBrick/1.3.1 (Ruby/2.2.1/2015-02-26)
Response body
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD><TITLE>Internal Server Error</TITLE></HEAD>
<BODY>
<H1>Internal Server Error</H1>
bad content body
<HR>
<ADDRESS>
WEBrick/1.3.1 (Ruby/2.2.1/2015-02-26) at
localhost:3000
</ADDRESS>
</BODY>
</HTML>
Server log:
[2015-05-22 16:12:57] ERROR EOFError: bad content body
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/multipart/parser.rb:96:in `block in fast_forward_to_first_boundary'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/multipart/parser.rb:94:in `loop'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/multipart/parser.rb:94:in `fast_forward_to_first_boundary'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/multipart/parser.rb:53:in `parse'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/multipart.rb:25:in `parse_multipart'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/request.rb:373:in `parse_multipart'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/request.rb:207:in `POST'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/methodoverride.rb:39:in `method_override_param'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/methodoverride.rb:27:in `method_override'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/methodoverride.rb:15:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/runtime.rb:18:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/activesupport-4.2.0/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/lock.rb:17:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/actionpack-4.2.0/lib/action_dispatch/middleware/static.rb:113:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/sendfile.rb:113:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/railties-4.2.0/lib/rails/engine.rb:518:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/railties-4.2.0/lib/rails/application.rb:164:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/lock.rb:17:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/content_length.rb:15:in `call'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/rack-1.6.1/lib/rack/handler/webrick.rb:89:in `service'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:138:in `service'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:94:in `run'
/Users/fufu/.rbenv/versions/2.2.1/lib/ruby/2.2.0/webrick/server.rb:294:in `block in start_thread'
Upvotes: 3
Views: 2287
Reputation: 46
I ran into this problem as well and it seems like Postman
is sending an empty body
when no POST parameters are defined. This trips up rails multipart parser because there is no ----WebKitFormBoundary7MA4YWxkTrZu0gW boundary delimiter
that is supposed to surround the body of the request, hence the unexpected EOF. The solution is to switch to x-www-form-urlencoded
(one of the 4 options under Body in Postman) instead.
Upvotes: 3