Rename AppendEncoded() to AppendHtml() and SetContentEncoded() to SetHtmlContent()

[kichalla]

In the following tag helper, I am using AppendEncoded to append <b> even though its not really encoded and is just raw content.

@NTaylorMullen suggested AppendRaw which seems like a good name to indicate what it does.

[HtmlTargetElement("greeting")]
public class GreetingTagHelper : TagHelper
{
    public string text { get; set; }

    public override void Process(TagHelperContext context, TagHelperOutput output)
    {
        output.TagName = null;
        output.Content.AppendEncoded("<b>");
        output.Content.Append(text);
        output.Content.AppendEncoded("</b>");
    }
}

@rynowak @dougbu

[dougbu]

Note <b> is just as fully-encoded as <b>. The only difference is you actually want to be bold in the first case.

[dougbu]

I suspect there's only three choices here but would love to hear something better:

1. Leave the name as-is.
2. Change to AppendRaw() which will be meaningful primarily to those familiar with @Html.Raw() and not necessarily to new MVC users.
3. Name the method to say exactly what it does AppendWithoutFurtherEncoding().

[Eilon]

AppendRaw() would indeed match up nicely with Html.Raw() - I would like that.

[Eilon]

I chatted with @dougbu and we both like AppendHtml. That makes it explicit that you can pass in HTML into it, and how you encoded the content in there (if at all), is totally up to the caller.

[NTaylorMullen]

Like it, 👍

[rynowak]

👍 love it!

[kichalla]

I like the name but wondering if it would make it a more attractive extension to be used when probably for most scenarios you want the content to be encoded?

[Eilon]

Oh it could certainly be an extension method if that simplifies the interface. The interface should have the minimum required. However, as far as how frequently it's used: I think HTML is just as common as non-HTML. Tag helpers, HTML helpers, etc. often have to render a lot of their own HTML plus page-generated stuff that needs to be encoded.

[rynowak]

Oh it could certainly be an extension method if that simplifies the interface.

We might not want to simplify the interface any further. An IHtmlContentBuilder needs to decide how it wants to represent the two kinds of string (encoded, unencoded). Making this an extension method means that you have to choose one of those as canonical, which is going to have a BAD perf impact on half the scenarios. It used to be this way, and I changed it based on the data.

However, as far as how frequently it's used: I think HTML is just as common as non-HTML. Tag helpers, HTML helpers, etc. often have to render a lot of their own HTML plus page-generated stuff that needs to be encoded.

The point about this that I was making earlier in the week is that you don't want to accidentally use AppendHtml when you mean Append. If it's not absolutely clear what the various methods do, then it's good that the unsafe one is scary 👻

• If you mistakenly use AppendHtml with unencoded text, you probably have an XSS vulnerability.
• If you mistakenly use Append with encoded text, you will have a double-encode - which is probably apparent just by looking at the site in a browser, and won't get your b0x0rs H4X0red

I think AppendHtml is better than AppendEncoded because it's clearer. Some others were saying that they found AppendEncoded confusing, and didn't know if it meant either:

• I want to encode this text and append it
• I want to append this encoded text

[Eilon]

Ok interface is fine then, and we'll go with AppendHtml.

[dougbu]

aspnet/HttpAbstractions@bcb56bd
aspnet/Razor@117bbe7
c267ef3