Fehlerbehandlung zur Thematik unbekannte Parameter, HTTP Status und canonical Link

Einheitliche Prozesse zur Fehlerbehandlung bei Requests mit unbekannten Parametern

In einem jeden Framework muß es einheitliche Prozesse geben: Von eingehenden Request bis zum Ausliefern der Response. Das heißt, daß keiner der konfigurierten URLs vom Ablauf her einer Sonderbehandlung bedarf, derart daß der Name des URL selbst im Programmcode notiert sein muss, so etwas würde die Wartbarkeit eines Frameworks ungemein erschweren. Aus diesem Grund betrachtet das hier vorliegende Framework (FW) jede Seite als Anwendung wobei es Anwendungen gibt, die ohne Parameter arbeiten und Anwendungen mit Parametern.

In dem Moment wenn ein Request, egal ob POST oder GET, Parameter enthält, stellt sich die Frage der Fehlerbehandlung bezüglich unbekannter oder nicht zulässiger Parameter. Um den Ablauf steuern zu können, verwendet das FW ein Attribut no_param, welches bei Anwendungen die ohne Parameter arbeiten gesetzt ist. Da Anwendungen die so konfiguriert sind, keine control()-Methode haben, kümmert sich das FW um den Fall, daß Parameter im Request sind und ruft die Methode noparam() auf:

# $ro ist das Request-Response-Objekt
# innerhalb der main-Class
    if($ro->param()){
        $ro->noparam if $ro->eav('no_param');
    }

Anwendungen die zur Verarbeitung von Parametern eingerichtet sind, haben innerhalb der control()-Methode eine Parameter-Kontrollstruktur und rufen bei einem fehlerhaften Request ebenfalls die o.g. Funktion noparam():

# Controller der an den URL gebundenen Klasse
sub control{
    my $self = shift;

    # Nur bestimmte Parameter erlauben
    my %valipar = ();
    my @inpar = $self->param;
    @valipar{@inpar} = @inpar;
    # erlaubte Parameter löschen
    delete @valipar{qw(find week year)};
    # was übrigbleibt ist bad request
    return $self->noparam
        if keys %valipar;

Einheitliche Fehlerbehandlung bei fehlerhaften Request

Die einer einheitlichen Fehlerbehandlung dienende Methode noparam() gibt den Status 400 Bad Request aus und baut in die Response eine Fehlermeldung ein:

sub noparam{
    my $self = shift;
    $self->header( Status => 400 );
    $self->errmsg("Unbekannter Parameter im Request!", $self->{URL});
    $self->eav('no_param','1');
}

Gut zu sehen, daß nun auch hier das Attribut no_param gesetzt wird. Mit diesem Attribut wird, soweit das für die Seite vorgesehen ist, schließlich der Einbau eines canonical Link gesteuert.

Die Frage des canonical Link

Für Anwendungen die mit Parametern arbeiten wird der kanonische Link ebenfalls mit Parametern gesetzt, somit ergibt sich auf der Zielseite exakt derselbe Inhalt: <link href="http://rolfrost.de/daysinkw.html?year=2017;week=50;find=1" rel="canonical">

Tritt jedoch ein Fehler auf, sorgt das Attribut no_param dafür, daß der kanonische Link zur Seite ohne Parameter führt: <link href="http://rolfrost.de/daysinkw.html">. Gleichzeitig wird die ursprüngliche Seite mit dem Status 400 ausgeliefert womit den Bots mitgeteilt wird, diese Seite nicht in den Index zu nehmen.

Die ganze Fehlerbehandlung erfolgt bis hierhin unabhängig von der Request-Methode. Bei Anwendungen die nur mit POST Parametern arbeiten, ist der ggf. zu erzeugende kanonische Link ohnehin ohne Parameter und das Attribut no_param ohne Belang. Somit ist er kanonische Link auch eine Folge der Fehlerbehandlung und nicht etwa die Lösung für eine Solche.


Die rein persönlichen Zwecken dienende Seite verwendet funktionsbedingt einen Session-Cookie. Datenschutzerklärung: Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. @: Rolf Rost, Am Stadtgaben 27, 55276 Oppenheim, nmq​rstx-18­@yahoo.de