This appears to have been intentionally implemented in ffd1c78 (https://golang.org/cl/14336) by @rsc

One possible workaround is to insert a template data key to insert the script type at evaluation time (tested on 1.8rc1)

https://play.golang.org/p/HbcDfwbXwq

this outputs the html you want without escaping on 1.8rc1.

<td class="api-key-cell"><%= key %></td>

@kennygrant that might be acceptable for smaller projects, but I have a number of these templates and also rely on some amount of template interpolation within them too. Consider:

<script type="text/template" id="form-template">
    <form class="new-form" path="/resource/{{.Id}}">
         <div><%= key %></div>    
    </form>
</script>

Assigning to @rsc to decide whether this is an acceptable change/regression for Go 1.8.

Wait, is the claim that "text/template" is the script type for EJS templates? When I saw that before I thought people were using that for Go templates.

This bug is filed with respect to the string "text/template" as in <script type="text/template">, not the Go package text/template.

From what I understand, marking script tags that you intend to use HTML templates as <script type="text/template"> is a common practice and not necessarily associated with EJS or any one other Javascript template framework. If the solution is just to make up a different value for the type attribute so that it won't be escaped, that is an acceptable solution.

Not sure if that answers your question - let me know if I can clarify anything! Thanks @rsc

It is a common practice to store HTML fragments inside script tags with a special type (usually text/template), like <script id="some-tmpl" type="text/template"><div class="...">...</div></script>, and then somewhere in the JavaScript code retrieving the contents and using it (e.g. in jQuery: $('#some-tmpl').html()).

OK, so what was happening before is that the <script> body was being treated as JavaScript, preserving things like < > symbols. Now it's being treated like HTML, and html/template doesn't recognize <%= %> and <% %> tags, so it de-tags them. This happens both inside and outside <script>s. The only workaround would be to tag your script javascript explicitly (or use the odd .Type hack, which probably shouldn't work).

$ cat /tmp/x.go
package main

import (
	"html/template"
	"os"
)

const tmpl = `
  <script id="new-key" type="text/template">
  <%= text/template %>
  </script>
  <script id="new-key" type="application/javascript">
  <%= application/javascript %>
  </script>
  <div id="my-div">
  <%= div %>
  </div>
`

func main() {
	template.Must(template.New("").Parse(tmpl)).Execute(os.Stdout, nil)
}
$ go1.7 run /tmp/x.go

  <script id="new-key" type="text/template">
  <%= text/template %>
  </script>
  <script id="new-key" type="application/javascript">
  <%= application/javascript %>
  </script>
  <div id="my-div">
  &lt;%= div %>
  </div>
$ go run /tmp/x.go

  <script id="new-key" type="text/template">
  &lt;%= text/template %>
  </script>
  <script id="new-key" type="application/javascript">
  <%= application/javascript %>
  </script>
  <div id="my-div">
  &lt;%= div %>
  </div>
$ 

The implementation of ffd1c78 makes scripts with unrecognized (non-JS) types treated like any other tag, meaning the body is HTML like the rest of the page. That seems about right, actually, but not here. I wonder if html/template should further understand that <% %> and <%= %> contain Javascript, or if that's too specialized. It sounds like otherwise we have to look for the </script> tag and leave everything uninterpreted until then.

I think the new behavior is the correct one. <% is neither valid HTML nor valid JS and should not be left unescaped by html/template, so as to not open the road to HTML/JS injection, and allowing specifically <% and %> seems too specialized (and error-prone). Those who wish to process EJS templates can make a copy of the html/template package and modify it accordingly to their needs. Another possibility is to opt in to not escaping things - say, a field in template.Template that you need to set to true before executing (parsing?) the template.

Mostly I'm confused by the intention of the this statement from the html/template documentation:

The security model used by this package assumes that template authors are trusted, while Execute's data parameter is not.

Escaping content that is actually in the raw template file itself seems like it presumes that the author is also not trusted and that this package is attempting to correct something the author has done wrong. If that statement were true, then an injected template.Javascript value should be treated the same was as a literal in the template itself, right? It seems redundant.

Agreed that treating <% or %> as special is probably an over-specialized thing to do. But there should be some fairly bold warning presented to people upgrading to 1.8, since I specifically selected EJS specifically to avoid using a different Javascript template framework that uses handlebars as delimiters, which overlaps with Go's template engines.

html/template must understand the meaning of the html tags in the input in order to understand which places need which escaping (for example <script> vs <div> or onclick= vs href=). My educated guess (without going searching) is that <% %> is escaped because html/template does not see it as a tag and does not want to emit something it doesn't understand that invalidates the security assertions it is making about the overall output.

I wonder if text/template could introduce a new action, {{ verbatim }}, which would allow everything between it and the {{ end }} action to be included in the result verbatim. A warning of the security risk would have to go to the docs, of course.

I think for this release the fix is going to be to use template.HTML (or the type indirection) to insert <% ArbitraryJS %> into your output.

Same problem for text/x-jsrender - which is the recommended type for jsrender templates - https://github.com/BorisMoore/jsrender#define-a-template. Context has switched from template.JS to template.HTML, which caused a failure for my app.

I'm switching to use template.HTML to fix this. Would really like a "just stick this text in the template output without escaping it" option that didn't care what the context was.

Looks like possible workaround is to temporary use mimetype from the list

$ go version
go version go1.8 darwin/amd64

Based on the discussion above and on the fact that there's a known workaround for non-JS, it seems like we should accept the new behavior, namely that only javascript is escaped as javascript.