Error sending empty Content-Type instrumentation.rb#22 #913

Closed
lighthouse-import opened this Issue May 16, 2011 · 2 comments

Comments

Projects
None yet
1 participant

Imported from Lighthouse. Original ticket at: http://rails.lighthouseapp.com/projects/8994/tickets/6546
Created by Pablo Cantero - 2011-03-09 02:50:19 UTC

Hi

I'm using Titanium to create an iPhone app which is integrating with my Rails app

Titanium XHR client, by default it is sending empty Content-Type. I don't know if it is a problem (it is a suggestion!), but when I try to access Rails app passing empty Content-type, I get this error

ConditionsController# (NoMethodError) "undefined method `to_sym' for nil:NilClass"

/app/3b9e4331-7f19-4831-85c3-a3d12c69c2e9/home/.bundle/gems/ruby/1.8/gems/rack-mount-0.6.13/lib/rack/mount/code_generation.rb:63:in to_proc' /app/3b9e4331-7f19-4831-85c3-a3d12c69c2e9/home/.bundle/gems/ruby/1.8/gems/actionpack-3.0.3/lib/action_controller/metal/instrumentation.rb:22:inmap'
...

This error occurs at this point ":formats => request.formats.map(&:to_sym)"

    # instrumentation.rb
    def process_action(action, *args)
      raw_payload = {
        :controller => self.class.name,
        :action     => self.action_name,
        :params     => request.filtered_parameters,
        :formats    => request.formats.map(&:to_sym),
        :method     => request.method,
        :path       => (request.fullpath rescue "unknown")
      }

The current error message not is clear, my suggest is to add a clear/specific error message

rescue "The Content-Type was not supplied" if request.formats.map.empty?, or use "Content-Type: text/html" as default

I created this ticket, because the current stacktrace for this problem is hard to understand, I spent a few hours to solve it. I also created a forum thread on Titanium Q&A

Pablo Cantero

Imported from Lighthouse.
Comment by Kenn Ejima - 2011-04-08 15:17:19 UTC

I had the same problem. In our case, some of our API client developers use Titanium and we have no control over what they choose, so I agree that at least we need an appropriate error (probably 400 Bad Request) raised that should be catched to respond an appropriate error JSON message to the client.

Or, to just go ahead without content type, probably Fjan's patch in this ticket could fix this problem as a more robust, generic fallback-to-html approach, to deal with future misbehaving clients?

https://rails.lighthouseapp.com/projects/8994/tickets/6022-content-negotiation-fails-for-some-headers-regression#ticket-6022-2

Imported from Lighthouse.
Comment by Neeraj Singh - 2011-04-09 17:20:12 UTC

Fix is here. See the last commit.

https://github.com/neerajdotname/rails/commits/fix_for_6546

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment