updated escape_html not to escape forward slash

[JunichiIto]

fix: #2096

NOTE: This PR will break backwards compatibility.

[jeremyevans]

Can you switch this to use CGI.escapeHTML if available for improved performance?

[ioquatix]

Can you switch this to use CGI.escapeHTML if available for improved performance?

I think we should do that, but I'm fine if it's a separate PR.

[ioquatix]

LGTM.

[JunichiIto]

@ioquatix
Thank you for your approve.

@jeremyevans
Thank you for your merge.

Can you switch this to use CGI.escapeHTML if available for improved performance?

I have not measured yet, but I guess Rack::Utils.escape_html would be faster because CGI.escapeHTML has more lines:

https://github.com/ruby/cgi/blob/v0.3.6/lib/cgi/util.rb#L74-L91

And some behaviors are different:

• Rack escapes ' to ' but CGI escapes to '. (hexadecimal vs decimal)
• Rack cannot escape \300< (raises "invalid byte sequence in UTF-8 (ArgumentError)"), but CGI can escape it because CGI converts encoding to ASCII-8BIT before calling gsub!.

I'm not sure if it can be replaced with CGI.escapeHTML.

Related commits

• 37ca253#diff-85960cbd609e7f51a9881d1876b82d748f4ba8312a31e3329a5bb9bf791c60beR135
• 5a942eb
• ruby/cgi@2900336

[jeremyevans]

CGI.escapeHTML is implemented in C in recent versions of the cgi gem, so it should definitely be faster (https://github.com/ruby/cgi/blob/master/ext/cgi/escape/escape.c#L458C6-L458C6). Basically, you require cgi/escape, if it succeeds you use it, and if it fails, then you can fallback to the existing implementation.

I don't think the behavior differences you mention are blockers to merging, though they may require test updates. CGI behavior using decimal is better as it saves a character :), and supporting non-UTF8 is also a useful feature.