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 use "=").

Also, the "dangerous HTML chars" depend on context: for a <script>, I
don't think any of those char is "dangerous" (given than
JSONObject.quote already escapes "/", producing a "<\/script"). For
another element (e.g. a <span style="display:none">), only < and & are
actual issues. And for attribute values, basically only quotes and & are
issues, possibly < and > though I believe they've only been issues with
really old browsers. Moreover, for all those chars, the HTML escape is
shorter than the JS escape (&lt; vs. \u003C, &#34; vs \u0022)

The comments below assume the above is refuted somehow.


http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java
File
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java
(right):

http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java#newcode78
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java:78:
case '/': sb.append("\\/"); break;
I don't think "/" needs escaping anymore if we escape "<". I guess it
was only escaped to avoid outputing "</script" that could close an HTML
script, but if "<" is escaped, it'd become "\u003C/script" where "/"
doesn't need to also be escaped.

http://gwt-code-reviews.appspot.com/1853803/diff/1/user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java#newcode86
user/src/com/google/web/bindery/autobean/shared/impl/StringQuoter.java:86:
if (c < ' ' || c >= 128 || DANGEROUS_HTML_CHARS.indexOf(c) != -1) {
Performance-wise, wouldn't it be better to add "case" lines above?

http://gwt-code-reviews.appspot.com/1853803/

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to