SharePoint Variations: HttpHandler anstatt VariationsRootLanding

Wenn die SharePoint Variations verwendet werden, so wird meistens auch die Standard SharePoint-Logik verwendet um den Redirect von der "LandingPage", d.h. der zentralen Einstiegs-Seite unter z.B. http://meineSharePointSite auf http://meineSharePointSite/deutsch/ usw. zu machen. Leider hat sich dies als alles andere als performant herausgestellt - und sendet zudem noch den falschen Http-Status Code zurück:

• 302: Temporarely Removed, anstelle von
• 301: Permanently Removed

Gerade für Internet-Seiten, welche gut indexiert werden sollten ist dies alles andere als fördernd.

Hinter den Kulissen passiert folgendes: Wenn die Variations-Hierarchien angelegt werden erstellt SharePoint eine neue Publishing-Seite mit dem PageLayout "Variations Root Page" und machte diese zur "Welcome Page", d.h. der Startseite der obersten Ebene der Website (respektive eben in der Ebene wo die Variations beginnen). Dieses PageLayout beinhaltet ein Control VariationsRootLanding.ascx, welches im 12er-Hive zu finden ist: 12\TEMPLATE\CONTROLTEMPLATES. Dieses Web-User-Control beinhaltet die Logik, welche feststellt, auf welche Sprach-Version/Variation der Benutzer umgeleitet werden soll. Der eigentliche Redirect findet dann mittels SPUtility.Redirect(targetUrl, SPRedirectFlags.Default, Context) im Page_Load Ereignis statt. Freundlicherweise hat Microsoft hier die gesamte Logik im Quell-Code der Datei eingepflegt und nicht in eine DLL-Kompiliert.

Nun könnten wir ja hingehen und diese Datei anpassen um sicherzustellen, dass der richtige HTML-Statuscode zurückgegeben wird. Allerdings ist dies nicht zu empfehlen, denn immerhin handelt es sich hier ja um eine SharePoint System-Datei und die könnte von einem Update oder Service-Pack überschrieben werden, von der Mühe, sich alle Anpassungen zu merken ganz zu schweigen...

Wie ich aber in verschiedenen Messungen feststellen konnte, sind Aufrufe auf die Standard Variations-Redirect-Seite enorm langsam. Dies ist dadurch erklärbar, dass die Seite wie eine normale Publishing-/Veröffentlichungsseite gehandhabt wird und auch einen beträchtlichen Teil des Lebenszyklus durchalufen muss, bevor dann endlich im Page_Load Ereignis die Umleitung stattfindet.

Deshalb setzte ich heute vielfach einen eigenen Http-Handler für die Redirects ein, also eine Klasse, welche IHttpHandler implementiert. Das Vorgehen ist denkbar einfach:

• Ein neues Visual Studio Projekt erstellen und das Projekt wenn nötig/gewollt mit einem "Strong-Name" versehen (GAC Deployment)
• Eine Klasse "VariationsRedirectHandler" erstellen, welche System.Web.IHttpHandler implementiert.
• Die Logik von Microsoft aus  VariationsRootLanding.ascx übernehmen und ergänzen, so dass der richtige Status-Code ausgegeben wird (hier darf nicht SPUtility.Redirect verwendet werden!). Natürlich kann hier auch eine eigene Logik implementiert werden!
• Die Assembly kompilieren und deployen

Alles, was uns jetzt noch fehlt ist ein Eintrag im Web.Config um den Http-Handler einzuschalten:

<httpHandlers>
      <remove verb="GET,HEAD,POST" path="*" />
      <add verb="*" path="/" type="FirstQuad.SharePoint.Publishing.VariationsRedirecttHttpHandler, FirstQuad.SharePoint.Publishing, Version=2.7.0.0, Culture=neutral, PublicKeyToken=9f4da00116xxxxxx" />
...
 </httpHandlers>

Dies funktioniert dann, wenn die Variations auf der obersten Ebene angelegt worden sind. Möchte man, dass der Handler auf einer anderen Ebene aktiv wird, ist die Sache etwas komplizierter: Man muss zwei Pfade registrieren:

• path="/myPath", und
• path="/myPath/"

Dies ist aber dann auch schon alles: Wir haben nun eine schnelle Umleitung, welche den richtigen Status-Code zurückgibt.

Im Folgenden noch ein Code-Beispiel/Auszug, wie ich den Code des Page_Load Ereignisses in die Methode ProcessRequest des IHttpHandlers übernommen habe:

public void ProcessRequest(HttpContext context)
{
    string targetUrl = this.GetRedirectTargetUrl();
    if (!string.IsNullOrEmpty(targetUrl))
    {
     Redirect(context.Response, 301, "/" + targetLocale.TwoLetterISOLanguageName);
    }
}

Die Methode Redirect habe ich von Nick Berardi's Coder Journal übernommen:

public static void Redirect(this HttpResponse response, int type, string url)  
{   
    response.Clear();   
  
    switch (type)   
    {   
        case 301:   
            response.StatusCode = (int)HttpStatusCode.MovedPermanently;   
            response.StatusDescription = "Moved Permanently";   
            break;   
  
        case 302:   
            response.StatusCode = (int)HttpStatusCode.Found;   
            response.StatusDescription = "Found";   
            break;   
  
        case 303:   
            response.StatusCode = (int)HttpStatusCode.SeeOther;   
            response.StatusDescription = "See Other";   
            break;   
  
        case 304:   
            response.StatusCode = (int)HttpStatusCode.NotModified;   
            response.StatusDescription = "Not Modified";   
            break;   
  
        case 307:   
            response.StatusCode = (int)HttpStatusCode.TemporaryRedirect;   
            response.StatusDescription = "Temporary Redirect";   
            break;   
  
        default:   
            goto case 302;   
    }   
  
    response.RedirectLocation = url;   
  
    response.ContentType = "text/html";   
    response.Write("<html><head><title>Object Moved</title></head><body>");   
    response.Write("<h2>Object moved to <a href=\"" + HttpUtility.HtmlAttributeEncode(url) + "\">here</a>.</h2>");   
    response.Write("</body></html>");   
  
    response.End();  
} 

Hinweis: Der Code ist zu umfangreich und auch spezialisiert für das Projekt um ihn gänzlich in diesem Blog zu publizieren. Ich gebe aber gerne weitere Auskünfte und auch Code-Fragemente auf Anfrage ab.




 

Kommentar

Kommentar hinterlassen Name: Email: Ihre URL: Kommentare: Sicherheitscode eingeben: