
I'm considering committing the following code to CoreJS SVN to solve the Safari escaping issue with Echo3. Will be reporting a bug @ bugreporter.apple.com as well.
Outgoing POST XHR containing text nodes with reserved XML characters are not being escaped. I just plain can't believe this browser is widely used with this kind of fundamental problem that apparently hasn't been fixed in years.
This code is going into Core.Web.HttpConnection
/**
* Creates a new <code>HttpConnection</code>.
* This method simply configures the connection, the connection
* will not be opened until <code>connect()</code> is invoked.
*
* @param {String} url the target URL
* @param {String} method the connection method, i.e., GET or POST
* @param messageObject the message to send (may be a String or XML DOM)
* @param {String} contentType the request content-type
* @constructor
*/
$construct: function(url, method, messageObject, contentType) {
this._url = url;
this._contentType = contentType;
this._method = method;
if (Core.Web.Env.BROWSER_SAFARI && messageObject instanceof Document) {
this._preprocessSafariDOM(messageObject.documentElement);
}
this._messageObject = messageObject;
this._listenerList = new Core.ListenerList();
},
_preprocessSafariDOM: function(node) {
if (node.nodeType == 3) {
var value = node.data;
value = value.replace(/</g, "<");
value = value.replace(/>/g, ">");
node.data = value;
} else {
var child = node.firstChild;
while (child) {
this._preprocessSafariDOM(child);
child = child.nextSibling;
}
}
},
While you're at it, here's
While you're at it, here's another one for Firefox: http://echo.nextapp.com/site/node/5230. A lot of our customers were affected by this, and are happily using the posted workaround for almost a month now. I should have filed an issue for this, but I was too lazy :)
Niels
Reported as bug#6085703
Reported as bug#6085703
18-Jul-2008 03:28 AM Tod Liebeck:
Summary:
Safari's XMLHttpRequest object sends an improperly formatted XML document to a server when POSTing data to the server.
Steps to reproduce:
1.) Create an XML document on the client using document.implementation.createDocument().
2.) Append a text node containing less-than/greater-than characters to an element of the document, e.g., node.appendChild(document.createTextNode("<foo><><><<<<"));
3.) Create an XMLHTTPRequest and post the document to the server. Pass the reference to the DOM itself to the XMLHttpRequest.send() method.
4.) View the received document text on the server.
Expected results:
On the server, we should see:
<foo><<<<</foo>
Actual results:
Safari will send:
<foo><<<<</foo>
Regression:
Tested with 3.1.2 (5525.20.1) on PPC. Have seen on lastest Intel version as well. Based on reports from our (NextApp) developer forums, this occurs in all versions of Safari, at least back to 3.0, likely the 2.x series as well.
Notes:
I'm currently using the following (horrible) workaround. I'm in the process of testing this, it appears to work so far, but need to look at other escapable elements (e.g., have not tested whether ampersands need to be escaped yet).
_preprocessSafariDOM: function(node) {
if (node.nodeType == 3) {
var value = node.data;
value = value.replace(/</g, "<");
value = value.replace(/>/g, ">");
node.data = value;
} else {
var child = node.firstChild;
while (child) {
this._preprocessSafariDOM(child);
child = child.nextSibling;
}
}
}