2014-05-14 5 views
2

J'ai un mystère à résoudre lors de la mise à niveau de notre application Rails3.2 Ruby 1.9 vers une version Rails3.2 Ruby 2.1.2. Nokogiri semble rompre, en ce sens qu'il change de comportement en utilisant open-uri. Aucune version de gemme n'est changée, juste la version ruby ​​(tout est sur OSX Mavericks, en utilisant brew, gcc4 etc).Ruby 2 Upgrade Breaks Nokogiri et/ou Open-URI Encodage?

Étapes pour reproduire:

$ ruby -v 
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-darwin13.1.0] 

$ rails console 
Connecting to database specified by database.yml 
Loading development environment (Rails 3.2.18) 

> feed = Nokogiri::XML(open(URI.encode("http://anyblog.wordpress.org/feed/"))) 
=> #(Document:0x3fcb82f08448 { 
    name = "document", 
    children = [ 
    .. 

> feed.xpath("//item").count 
=> 10 

Alors tout va bien! Ensuite, après un changement de RVM à Ruby 2.1.2 et un paquet installer ..

$ ruby -v 
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin13.0] 

$ rails console 
Connecting to database specified by database.yml 
Loading development environment (Rails 3.2.18) 

> feed = Nokogiri::XML(open(URI.encode("http://anyblog.wordpress.org/feed/"))) 
=> 

> feed.inspect 
=> "#<Nokogiri::XML::Document:0x86a1f21c name=\"document\">" 

> feed.xpath("//item").count 
=> 0 

Il semble donc que le « ouvert » le codage a changé, en ce qu'un flux http gzip n'est pas alimenté correctement Nokogiri ? J'ai vérifié avec un nokogiri -v et il utilise les bibliothèques xml empaquetées plutôt que celles du système. Est-ce un problème open-uri Ruby 2.1.2?

Une autre théorie est que l'une des gemmes a un URI ouvert modifié par singe pour fixer quelque chose en 1.9 et qui se brise en 2.1? Aide ou idées s'il vous plaît!

EDIT: Voici plus d'informations ne pas utiliser Nokogiri, à savoir penser ce qui est plus une question ouverte sur uri Ruby 2.1.2:

> open(url) {|f| 
* f.each_line {|line| p line} 
* p f.content_type 
* p f.charset 
* p f.content_encoding 
* } 
"\u001F\x8B\b\u0000\u0000\u0000\u0000\u0000\u0000\u0003\xED\x9D\xDBr\eW\xB2\xA6\xAF\xED\xA7\xA8\xCD\u001E\xB7/$\u0010.. 
(snip) 
3\xF3\xA79\xA7\xFAɗ\xFF\u000F\xEAo\x9C\u0014k\xE8\u0000\u0000" 
"text/xml" 
"utf-8" 
["gzip"] 
=> ["gzip"] 

..la version 1.9 est lisible, à savoir gzip était déjà appliquée. Si je vais dans un irb ruby ​​propre ça marche bien, donc ça doit être quelque chose dans mes rails gems qui change le comportement de open-uri ouvert pour ne pas dégonfler/gzip. J'ai beaucoup de gemmes référencées .. :(

Répondre

2

Ok, voici une réponse, et peut-être la réponse: Ruby 2 a changé comment il utilise les en-têtes dans les requêtes HTTP et zipper/dégonfler, mais à un moment donné, ils ont changé d'avis Dans l'intervalle, certains mainteneurs de pierres précieuses de Rails ont corrigé HTTP: Net pour que leurs gemmes fonctionnent à la fois sur 1.9 et 2.0. Ces correctifs de singe persistent encore dans les anciennes versions de gemmes et provoquent des problèmes comme ceux que j'ai vus. 1,9 à 2,1

Un résumé de la question et la solution ici:

http://avi.io/blog/2013/12/17/do-not-upgrade-your-rails-project-to-ruby-2-before-you-read-this/

Nous utilisons les right_aws de pierres précieuses, et les détails de cette question avec les versions de rubis est ici:

https://github.com/sferik/twitter/issues/473

La solution était de défaire le patch de singe en utilisant comme référence bijou dans notre Gemfile:

gem 'right_http_connection', git: 'git://github.com/rightscale/right_http_connection.git', ref: '3359524d81' 

lecture et plus d'informations:

https://github.com/rightscale/right_aws/issues/167