Protect dumb JavaScript engines from having to deal with actual Unicode

The holdings_xml format did not include an XML declaration, but adding that
as we do here still does not make the Firefox and Chromium JS engines capable
of consuming XML that contains Unicode content outside of the base ASCII
range.

So, we invoke entityize() to convert anything outside of the realm of
ASCII to XML entities. An alternative would be to invoke entityize() in
OpenILS::Application::SuperCat::unAPI::acn but it's not clear if that
would interfere with any other uses.

With this change, library names / copy location names with Unicode content
can be displayed correctly on the search results page.

git-svn-id: svn://svn.open-ils.org/ILS/trunk@20112 dcc99617-32d9-48b4-a31d-7c20da2025e4

diff --git a/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm b/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm
index 1e7c75a..a0dfea9 100644 (file)
--- a/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm
+++ b/Open-ILS/src/perlmods/lib/OpenILS/WWW/SuperCat.pm
@@ -680,12 +680,19 @@ sub unapi {
         return 404;
     }
 
-    print "Content-type: application/xml; charset=utf-8\n\n$data";
+    print "Content-type: application/xml; charset=utf-8\n\n";
 
+    # holdings_xml format comes back to us without an XML declaration
+    # and without being entityized; fix that here
     if ($base_format eq 'holdings_xml') {
+        print "<?xml version='1.0' encoding='UTF-8' ?>\n";
+        print $U->entityize($data);
+
         while (my $c = $req->recv) {
-            print $c->content;
+            print $U->entityize($c->content);
         }
+    } else {
+        print $data;
     }
 
     return Apache2::Const::OK;