proposal: html/template: escape unquoted attributes by first quoting them #43224
We allow actions to appear in "Unquoted Attribute" contexts.
This means this template is valid:
To support this when we escape we have to take some extra care to escape all whitespace (which would break the token) and we rely on some niche behaviors of the spec.
For example if we render the template above with "da ta/" we get
<img src=da ta/>
Which looks an awful lot like an ambiguous syntax. (Playground link)
It turns out that if you follow the spec this should parse as
But I find this behavior very brittle, especially considering that the escaping character set that we use currently was retrieved by using a bit of the spec and a custom script we never re-run:
Change this escaping to run two passes:
This would remove the need for
I found this while looking into #42506
The text was updated successfully, but these errors were encountered:
How about detecting first, whether quoting and/or escaping is needed at all, and foregoing it otherwise?
One of the first pieces of Go code I ever wrote was for this exact purpose:
It does take at most two passes over the string (one to detect quotables and to pick a quote, other to emit escaped quote), but IMO the benefit balances the cost.
This will definitely break some tests so I am proposing this change to weigh with you all if this looks like it is worth the cost. If you think it would make it clearer that this is not an API change I can rename this to be a normal feature request rather than a proposal.
@antichris Thanks for the suggestion. One of the reasons I am proposing this is to simplify the logic in this package and make it more consistent. While your proposal would indeed make escaped strings shorter it would definitely make the logic more complex and the rendered HTML less consistent. Unless you can find a common use case that foresee a big amount of quotes in an HTML attribute value I'd rather keep it simpler and always use the same quotes. Does this make sense to you?
I support this. html/template is meant to be secure and easy to use, not to allow ultimate control over how the generated HTML looks like (as opposed to how it behaves). If we can generate output that is equivalent but is safer and simpler, sounds great.
I got two right off the top of my head:
And then there's also inline style and scripts (
You're, of course, right. However inlining resources is unavoidable for certain common cases, e.g.: e-mails.
Does it make sense to introduce a new function to the API to be more opinionated in these specific cases? Providing more context by exposing a slightly richer API might: keep the logic simpler, allow to stay backwards compatible yet provide to the proposal.
The reason I'm pitching in is because of #42506 which might be solved by hitchhiking on this issue