Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

Error sending empty Content-Type instrumentation.rb#22

#6546

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

Reported by Pablo Cantero · March 9th, 2011 @ 02:50 AM

State: open
Milestone: none
Assigned to: José Valim José Valim
Importance: Low

Activity

  1. Kenn Ejima
    Kenn Ejima

    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?

    #6022 Content negotiation fails for some */* headers (regression)

    April 8th, 2011 @ 04:17 PM

  2. Neeraj Singh
    Neeraj Singh
    • State changed from new to open
    • Assigned user set to José Valim
    • Importance changed from to Low

    April 9th, 2011 @ 06:20 PM