On 2012/10/13 03:42:46, cromwellian wrote:
One option is to have an extra method like encodeForHtmlContext()
where you only
pay the tax in that circumstance.
Would it cost really that much to post-process the output from AutoBeans
(possibly depending on context)?
For instance, using OWASP
I don't think it's a matter of simple character replacement once
something has been serialized to JSON string. For example, these
encoders will typically escape '\' character, but if there are already
legal escape sequences in the string, it will end up double-escaping
the payload leading to
On Saturday, October 13, 2012 12:30:24 PM UTC+2, Ray Cromwell wrote:
I don't think it's a matter of simple character replacement once
something has been serialized to JSON string. For example, these
encoders will typically escape '\' character, but if there are already
legal escape
The context IIRC from internal discussion, is something writing
something like this:
script
var x = 'autoBean result'; //e.g. what you don't want
var x = '{foo: \u0061, don't stop believin'}'
/script
The codec you linked to to me looks like it will change backslash into
\x5c form perusing
Should HTML-specific escaping be done on top of the value produced by
AutoBeans? Do we really want to pay the tax (each one of =' is
replaced by 6 chars!) for each AutoBean-based exchanged over the wire
(for example, RequestFactory uses Base64-encoding for its stableId and
version, which makes
One option is to have an extra method like encodeForHtmlContext() where
you only pay the tax in that circumstance.
http://gwt-code-reviews.appspot.com/1853803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
