klaus_b@.NET

… ist es überhaupt möglich?
Ja; allerdings sind dazu einige “Kunstkniffe” nötig.
Als erstes müssen die diversen &–Zeichen im HTML durch die korrekte Entität & ersetzt werden. Außer den eigenen Widgets, Benutzersteuerelementen oder Erweiterungen, bietet hier BlogEngine.NET noch jede Menge Vorkommen im Quellcode. Die meisten sind leicht mit Hilfe der Suche zu finden. Einige verstecken sich jedoch an ungeahnten Stellen. Folgend zwei Beispiele, für zwei üble Verstecke die leicht übersehen werden können.

Als erste das Benutzersteuerelement CommentView.ascx im jeweils verwendeten Theme-Ordner. Es stellt mit den jeweiligen Kommentaren auch die URL der Webseite des Kommentator dar. Darunter fallen auch die Webseiten von angegebenen Trackback oder Pingback-Kommentaren.
Diese enthalten oftmals Parameter und somit auch das &-Zeichen. Das Benutzersteuerelement stellt den Wert der Eigenschaft Comment.Website einfach in einer Verknüpfung mit dem Namen des Kommentators dar, ohne den Inhalt der Eigenschaft zu überprüfen. bzw. zu kodieren.
An dieser Stelle schafft ein einfaches Kodieren mittels HtmlEncode Abhilfe.

<div class="visitor">
	<%= Comment.Website != null
		? "<a href=\"" + this.Server.HtmlEncode(Comment.Website.ToString()) + "\" rel=\"nofollow\" class=\"url fn\">" + Comment.Author + "</a>"
		: "<span class=\"fn\">" + Comment.Author + "</span>" %>
    <%= Flag %>
    <div class="comment_date"><%= Comment.DateCreated %><a href="#id_<%=Comment.Id %>">#</a></div>
</div>

Ein weiteres Versteck ist die Klasse Avatar.cs im Projekt DotNetSlave.BusinessLogic.
Diese Klasse wird vom Benutzersteuerelement CommentView.ascx zur Darstellung des Avatar eines Kommentators verwendet. Dabei wird als src-Attribut des img-Tag die angegebene Track- oder Pingback Adresse verwendet, um mit websnapr.com eine Grafik als Avatar darzustellen.
Der Entwickler der Klasse Avatar.cs hat hier versucht die URL der Webseite via UrlEncode zu entschärfen. Doch leider wird bei der Kodierung mit UrlEncode das &-Zeichen nicht übersetzt. Hierzu muss HtmlEncode verwendet werden. Die betreffende Stelle ist im Quellcode der Datei Avatar.cs bei Zeile 92 zu finden.

url =
    new Uri(
        string.Format(
            "http://images.websnapr.com/?url={0}&size=t",
            HttpUtility.HtmlEncode(website.ToString()))); //HttpUtility.UrlEncode(website.ToString())));

Soweit zu den Anpassungen in BlogEngine.NET.
Als nächstes muss eine Unart von ASP.NET beseitigt werden, ohne die eine Validierung höher als XHTML1.0 Transitional nicht möglich ist. Es geht dabei um das name-Attribute des form-Tags, das außer von ASP,NET von niemandem sonst benötigt wird. Nur so einfach wird man dieses Attribut nicht los. In der Deklaration einer Form in Visual Studio, ist das Attribute nicht vorhanden. Es wird erst beim verarbeiten der Form von ASP.NET hinzugefügt. Demzufolge muss das Attribut auch erst nach der Verarbeitung wieder Entfernt werden.

Die einfachste Möglichkeit um das ungeliebte Attribut loszuwerden, bietet die Verwendung eines HttpResponse.Filter, wie schon einmal im Artikel über das Entfernen von nutzlosen Whitespace zur Laufzeit gezeigt. So ein Filter ist nichts weiter als eine Klasse die von der abstrakten Klasse Stream erbt. In ihr wird in der Methode Write der form-Tag entsprechend bearbeitet.

public override void Write(byte[] buffer, int offset, int count)
{
    var sb = new StringBuilder(this.ResponseEncoding.GetString(buffer));
    sb.Replace("<form name=\"aspnetForm\"", "<form");
    HtmlOptimizationFilter.CorrectErrors(sb);
    foreach (var entry in this.CommentsToRemove)
    {
        sb.Replace(entry, null);
    }
    if (this.TranslateEntities)
    {
        HtmlOptimizationFilter.TranslateHtmlEntities(sb);
    }
    var outData = this.RemoveUnneededWhiteSpaces
        ? HtmlOptimizationFilter.RemoveWhiteSpaces(sb, this.ResponseEncoding)
        : this.ResponseEncoding.GetBytes(sb.ToString());
    this.sink.Write(outData, 0, outData.GetLength(0));
}

Hier ist nur die Zeile 284 von Belang. Der andere Code in der Methode kann ignoriert werden.
Damit der Filter auch verwendet wird, muss er natürlich auch irgendwo in die Anwendung eingebunden werden. Innerhalb von BlogEngine.NET bietet sich das enthaltene Kompressionsmodul CommpressionModule.cs im Projekt DotNetSlave.BusinessLogic an, da hier bereits ein eigener Filter verwendet wird. In der statischen Methode ContextPostReleaseRequestState kann der Filter folgendermaßen verwendet werden:

private static void ContextPostReleaseRequestState(object sender, EventArgs e)
{
    var context = ((HttpApplication)sender).Context;
    if (context.CurrentHandler is Page
        && context.Request["HTTP_X_MICROSOFTAJAX"] == null
        && context.Request.HttpMethod == "GET")
    {
        CompressResponse(context);
        context.Response.Filter =
            new HtmlOptimizationFilter(context.Response.Filter)
            {
                CommentsToRemove = new string[]
                {
                    "<!-- Start custom code -->",
                    "<!-- End custom code -->"
                },
                RemoveUnneededWhiteSpaces = true,
                TranslateEntities = true
            };
        if (BlogSettings.Instance.CompressWebResource)
        {
            context.Response.Filter = new WebResourceFilter(context.Response.Filter);
        }
    }
    else if (!BlogSettings.Instance.CompressWebResource
			  && context.Request.Path.Contains("WebResource.axd"))
    {
        context.Response.Cache.SetExpires(DateTime.Now.AddDays(30));
    }
}

In Zeile 134 wird der Filter verwendet und der bisherige Filter, der ja auch ein Objekt vom Typ Stream darstellt, an den Filter übergeben. Die an die verschiedenen Eigenschaften des Filter übergebenen Werte sind im Moment nicht weiter wichtig.

Jetzt muss nur noch der richtige Doctype in der Masterpage des verwendeten Theme eingesetzt werden und der Validierung nach XHTML1.1 steht nichts mehr im Weg.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Wahrscheinlich werden bei den ersten Versuchen noch ein paar Fehler oder Warnungen, betreffend des einen oder anderen übersehenen Steuerzeichens auftauchen. Die “gröbsten Schnitzer” sollten allerdings bereits beseitigt sein.
Interessierte können sich den verwendeten Filter gerne herunterladen.

HtmlOptimizationFilter.zip

Fazit:

Ist die Umstellung des Doctype von XHMTL1.0 Transitional auf XHTML1.1 überhaupt nötig?
Für den alltäglichen Gebrauch des Blog sicher nicht. Mit dem Fortschreiten der Entwicklung von (X)HTML5 gewinnt valider Code immer mehr an Bedeutung. Mich reizte der Gedanke, die Codebasis von BlogEngine.NET gegen den experimentellen HTML5-Validator zu testen. Das Ergebnis war überraschend:
Würde ich mich vom meta-Tag PICS-Label trennen, währe die aktuell von mir verwendete Codebasis valide nach dem jetzigen Stand des HTML5-Validator.
Es währe allerdings Unsinn, zum jetzigen Zeitpunkt auf XHTML5 umzustellen, da aus der Codebasis von BlogEngine.NET einfach zu wenig Semantik zu holen ist.

Wenn ihnen der Artikel gefallen hat oder er für sie hilfreich war, bitten "kicken" sie ihn.