REST content type issues. "X-Content-Type-Options" value="nosniff"

It looks like browsers have started blocking web requests to resources that have the content type option of "nosniff" set where the returned mime type does not match the content type.  This has broken an approach we have been using to run a workflow via jquery web request in an external application and handling the results.

Example that was working:

var inargs_values = '[{"isRequired":false,"name":"geotype","typeName":"System.String, mscorlib","runtimeTypeName":"System.String,mscorlib","value":"all"}]';
$jq.ajax({
                type: "GET",
                contentType: "application/json; charset=utf-8",
                data: {
                  inargs: inargs_values
                },
                dataType: "jsonp",
                processData: true,
                url: essentialsRoot + 'workflows/getplaces/run?f=json'
              });

Recently this has started breaking with a browser console error showing that the returned mime type from the Essentials REST request was text/plain with the nosniff option set.  I tried to change the content type in the request to text/plain but that didn't work.

was blocked due to MIME type (“text/plain”) mismatch (X-Content-Type-Options: nosniff)

It appears that possibly in one of the recent essentials updates, the following was added to the REST web.config.

<httpProtocol>
      <customHeaders>
        <remove name="X-Content-Type-Options" />
        <add name="X-Content-Type-Options" value="nosniff" />
      </customHeaders>
    </httpProtocol>

If I comment out the      
        <!--<add name="X-Content-Type-Options" value="nosniff" />-->

I get results again.

Presumably we will need to remember to comment this out each time we upgrade Essentials unless there is another way to ensure that the results from the REST requests to workflows is returned as json instead of plain text?

-- Marc