2016-06-06 4 views
0

Ich versuche, ein paar Meinungen, die ich in freier Wildbahn gefunden habe, zu versöhnen. Eine Quelle sagt, dass in C# Request.UrlReferrer eine System.UriFormatException auslösen wird, wenn der HTTP-Header fehlerhaft ist. Die andere besagt, dass Request.UrlReferrer in diesem Fall tatsächlich keine Ausnahme auslöst, sondern null zurückgibt.Muss ich mich bei Verwendung von Request.UrlReferrer vor fehlerhaften HTTP-Headern schützen?

Das heißt, ich entwickle eine Webapp, die die Referral URL für zukünftige Referenz erfassen wird. Ich überprüfe es auf Null, so dass der Fehler "nicht auf Instanz eines Objekts gesetzt" bei der Umwandlung in eine Zeichenfolge usw. nicht platzt und dies gut ausgeht. Ich frage mich auch, ob ich Fehlerbehandlung für mögliche System.UriFormatExceptions einschließen sollte.

Hat jemand in das hineingeraten? Vielen Dank!

EDIT: Angesichts NightOwl888's Antwort unten scheint es, dass Ausnahmen auftreten können. Wie oft, ich bin mir nicht sicher, aber ich würde lieber dagegen schützen, als auf einer öffentlichen Site Ausnahmen zu riskieren.

Ich nehme nur die ReferralUrl für die Protokollierung, so dass es nicht in einem nachgelagerten Anwendungskontext verwendet werden wird. Es ist nur grannGiven immer, dass ich vermute, dass der folgende Code sollte mich decken:

Uri referrer = null; 
     try 
     { 
      referrer = Request.UrlReferrer; 
     } 
     catch (UriFormatException) 
     { 
      referrer = null; 
     } 
     catch (Exception) 
     { 
      referrer = null; 
     } 
     var referralUrl = (referrer != null) ? referrer.ToString() : "None Found"; 

EDIT: Changed Ausnahmen und hinzugefügt allgemeinen Fang

+0

Wie für Ihre Bearbeitung: Sie sollten 'UriFormatException' (oder um sicher zu sein,' Exception') fangen, weil die Eigenschaft nie eine 'HttpException' werfen wird. Das ist der eine Fall, bei dem es stattdessen "null" zurückgibt, also ist Ihr Ausnahmebehandler ein nicht erreichbarer Ausführungspfad wie er jetzt ist. – NightOwl888

+0

Ja, danke. Ich habe mich geirrt. Ich habe nach meinem letzten Update einen allgemeinen Fang hinzugefügt. Danke noch einmal! – ewomack

Antwort

0

Überprüfung der Quelle der System.Web.HttpContext.Current.Request.UrlReferrer zeigt folgende.

public Uri UrlReferrer 
{ 
    get 
    { 
     if ((this._referrer == null) && (this._wr != null)) 
     { 
      string knownRequestHeader = this._wr.GetKnownRequestHeader(0x24); 
      if (!string.IsNullOrEmpty(knownRequestHeader)) 
      { 
       try 
       { 
        if (knownRequestHeader.IndexOf("://", StringComparison.Ordinal) >= 0) 
        { 
         this._referrer = new Uri(knownRequestHeader); 
        } 
        else 
        { 
         this._referrer = new Uri(this.Url, knownRequestHeader); 
        } 
       } 
       catch (HttpException) 
       { 
        this._referrer = null; 
       } 
      } 
     } 
     return this._referrer; 
    } 
} 

also in der Tat ist es möglich, dass ein UriFormatException kann auftreten, wenn die URL ungültig ist, da HttpException die einzige Art ist, die null und UriFormatException does not inherit from HttpException gesetzt.

Eine bessere Option könnte die Verwendung Request.Headers["Referer"] sein, die die rohe Zeichenfolge als pointed out here zurückgibt. Beachten Sie jedoch, dass der Header einen beliebigen Wert enthalten kann (einschließlich Werten, die keine URLs sind).

IMO, die Referer -Header sollte nur für Protokollierungszwecke verwendet werden, da es nicht zuverlässig genug ist, um jede Art von Anwendungsfunktionalität zu implementieren (es sei denn, es gibt eine Art von Backup-Funktionalität im Falle, dass es fehlt oder fehlerhaft). Der Browser kann (und tut es oft) in bestimmten Fällen nicht senden.

+0

Danke! Ich habe mich auf diesen Weg gelehnt und du hast es bestätigt. Ich bearbeite meinen obigen Text auch vor diesem Hintergrund – ewomack