Interesting
String#to_xs behavior can change if you happen to have the fast_xs gem installed.
Rails tries to require the ‘fast_xs’ c-extension to implement String#to_xs (it falls back to a pure Ruby XML escaping algorithm if it can’t find it). Unfortunately, fast_xs is not API compatible with the built-in version provided by Rails (it escapes double quotes, for no apparent reason).
This is all well and good if that’s what you decide go with. But unfortunately, fast_xs is a c-extension, which means that if it’s been installed on your system for whatever reason (say, installing Hpricot), then Rails will start using it, and there’s no good way to turn it off (unless you consider hacking your ActiveSupport gem “good”). So the behavior of your app could change without any explicit intention on your part.
fast_xs also exists as a gem that wraps the c-extension, and if you use to_xs (i.e. your app emits XML), it might behoove you to depend on the gem explicitly. It was noted that for apps that emit a lot of XML to be performant, you will need fast_xs, anyway.
Interestingly, it turns out that JRuby has yet a third implementation of #fast_xs which will escape the XML differently than both the ActiveSupport ruby implementation of #to_xs and the fast_xs C extension.
In summary:
#to_xs (ActiveSupport): escapes < , >, and &
#fast_xs (C): escapes < , >, &, and ”
#fast_xs (JRuby): escapes < , >, &, “, and ‘ (and possibly others)
As with the C version, if you’re using JRuby you get the JRuby version whether you like it or not.
October 7, 2009 at 4:23 pm
Grrr, markdown.
* #to_xs (ActiveSupport): escapes < , >, and &
* #fast_xs (C): escapes < , >, &, and ”
* #fast_xs (JRuby): escapes < , >, &, “, and ‘ (and possibly others)
October 7, 2009 at 4:24 pm
To be clear, the Java implementation of #fast_xs comes from Hpricot, not from JRuby itself. Installing the Hpricot gem using JRuby brings in the hpricot-java library, which has the not-consistent-with-anything-else implementation of #fast_xs.
October 7, 2009 at 6:21 pm
Coworker and I just spent 3 hours trying to figure out why is our Rails loading activating the Hpricot 0.8.1 gem without us specifying it.
We pinpointed fast_xs by augmenting `Gem.activate` method to raise an error whenever it tries to activate the ‘hpricot’ gem. This left me wondering is there a more graceful method to debugging such load issues.
October 8, 2009 at 6:17 am
@mislav – I first try using RubyGems reverse dependency command:
gem dependency -R hpricot
That will tell you what depends on hpricot. Sometimes this is difficult, though, especially if there is a long dependency chain.
October 20, 2009 at 1:17 pm