what is the best place to handle escaping (html encoding) when using VF Remoting?
I think it is exactly because of fragmentation around front-end frameworks, that Salesforce have defaulted the escaping up into the transport layer. They know the behaviour really doesn't belong there but it's for safety's sake! So they avail the escape parameter on RemoteAction invocations. This allows developers to make the right call under the right circumstances.
most client side frameworks would handle the escaping?
Yes! If one embraces a serious client-side stack like Sencha Ext, most content that reaches the presentation layer through bound components (eg grids) is escaped by default. As you note, doing this on the transport causes double escaping. To a purist, comms are the responsibility of the data layer (that means Stores and Proxies in Sencha) and it fully expects data on the wire NOT to be escaped.
Conversely, when using Salesforce's main MVC presentation layer (Visualforce and Apex). all content that reaches the page is already escaped by default. To get at unescaped content, you have to be very explicit by using apex:outputText element with escape=false attribute to get at unescaped content.
I see the difference as being: with VF+Apex we can't accidentally leave content unescaped. Whereas with Remoting and the client-side stack, it is easier for unescaped content to slip out by oversight alone.
what is the best practice for this?
Depends. From a best practises point of view, if one escapes universally (including when inappropriate) then developers will have to unescape the data manually before dealing with it anyway, which just reintroduces the problem with someone else to blame.
Definitely I appreciate the need for processes and procedures (eg escape by default) but legitimate exceptions exist. And if developers don't bother using the output layer of the framework it's all moot anyway ;-)
Underescaping is not without risk, even if it's an internal-only interface:
- malicious users can plant code that leaks data, eg
- dirty data can break the app, eg
United Oil & Gas <DOES NOT PAY INVOICES> (open tag!)
Overescaping is also not harmless:
- an ampersand will expand to
&&&&&;;;; over time as a record gets saved
- special characters in any field will gradually get dirtier and dirtier
Depends what you consider the lesser evil, and whether it pollutes your application architecture.