Bugs item #2727, was opened at 2005-10-27 21:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2727&group_id=426 Category: Standard Library Group: None Status: Closed Resolution: Out of Date Priority: 3 Submitted By: Luke Kanies (lkanies) Assigned to: Nobody (None) Summary: XMLRPC::ParseContentType#parse_content_type raises non-XMLRPC exception Initial Comment: I have now run into this problem multiple times. I keep managing to send data that XMLRPC is not expecting, and the call to 'split' in this method (XMLRPC::ParseContentType#parse_content_type) raises a NoMethodError exception instead of an XMLRPC exception: test_logclient(TestLogger) [logger.rb:140:in `test_logclient' logger.rb:135:in `each' logger.rb:135:in `test_logclient']: Exception raised: Class: <NoMethodError> Message: <"private method `split' called for nil:NilClass"> ---Backtrace--- /usr/lib/ruby/1.8/xmlrpc/utils.rb:166:in `parse_content_type' /usr/lib/ruby/1.8/xmlrpc/client.rb:538:in `do_rpc' /usr/lib/ruby/1.8/xmlrpc/client.rb:409:in `call2' /usr/lib/ruby/1.8/xmlrpc/client.rb:399:in `call' This call to 'split' should be protected with begin/rescue blocks, so that it raises the correct kind of exception, or the parent call should do so. This time the problem occurred because I have an xmlrpc method that does not have a return value, so I wasn't returning anything, which resulted in nil content, which threw everything off. Having the XMLRPC method return "" fixed the bug, but it seems like error handling for this case should be better. Thanks, Luke ---------------------------------------------------------------------- Comment By: Robert Read (rread) Date: 2007-04-10 11:56 Message: I'm seeing this in 1.8.6, and this ccurs whenever Content-Type is not set in the response. This simple patch avoids the error in that case, and assumes the data is xml: Index: lib/xmlrpc/client.rb =================================================================== --- lib/xmlrpc/client.rb (revision 12167) +++ lib/xmlrpc/client.rb (working copy) @@ -546,15 +546,17 @@ module XMLRPC raise "HTTP-Error: #{resp.code} #{resp.message}" end - ct = parse_content_type(resp["Content-Type"]).first - if ct != "text/xml" - if ct == "text/html" - raise "Wrong content-type: \n#{data}" - else - raise "Wrong content-type" + unless resp["Content-Type"].nil? + ct = parse_content_type(resp["Content-Type"]).first + if ct != "text/xml" + if ct == "text/html" + raise "Wrong content-type: \n#{data}" + else + raise "Wrong content-type" + end end end - + expected = resp["Content-Length"] || "<unknown>" if data.nil? or data.size == 0 raise "Wrong size. Was #{data.size}, should be #{expected}" ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2006-11-01 23:19 Message: I'm closing this bug due to its age / staleness. I simply can't triage them all and I have to cut corners somewhere. If you believe this bug still exists in the latest version of ruby 1.8.x, please reopen it and, if you can, attach a minimally reproducible test case to help us repro it in 1.8.x (where x >= 5). Thank you for your support. Things will get better. Ryan Davis. ---------------------------------------------------------------------- Comment By: Luke Kanies (lkanies) Date: 2006-01-16 18:18 Message: I can't seem to replicate this bug. I didn't notice your comment until just now, which is why it's taken so long for me to respond. Isn't it at least reasonable to add some protection around that call, since you've got output showing it's possible to end up with nil there? I've written up an example that comes as close as I could to replicating what I am doing; incidentally, it fails with a RuntimeError instead of an XMLRPC error, but I guess that would be a different bug. ---------------------------------------------------------------------- Comment By: Nobody (None) Date: 2005-11-01 02:44 Message: Could you please submit a little example code snippet (client and server), where this bug occurs? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=1698&aid=2727&group_id=426