Christoph B.: PHP: Unterseiten-Name anpassen (SEO)

0 47

PHP: Unterseiten-Name anpassen (SEO)

Christoph B.
  • php
  1. 0
    dedlfix
    1. 0
      Tagwächter
      1. 0
        TS
        1. 0
          Tagwächter
      2. 0
        dedlfix
        1. 0
          Tagwächter
      3. 0
        MudGuard
        1. 0

          Allfällige Korrektur

          Tagwächter
  2. 0
    TS
    1. 0
      pl
      1. 0
        TS
        • apache
        1. 0
          pl
          1. 3
            Tagwächter
  3. -1
    Google weiß alles
    1. 0

      Nicht hilfreich?

      Google weiß alles
      • php
      • zu diesem forum
      1. 0
        dedlfix
        • menschelei
        • zu diesem forum
        1. 0
          Google weiß alles
          1. 0
            dedlfix
            1. 0
              Tagwächter
              • menschelei
              1. 0
                dedlfix
      2. 0

        Fehlender Test

        Google weiß alles
      3. 1
        dedlfix
        1. 0
          Tagwächter
          1. 1
            dedlfix
            1. 0
              Tagwächter
              1. 0
                Tagwächter
            2. 0
              TS
              • apache
              • php
              1. 0
                Tagwächter
                1. 0
                  TS
                  1. 0
                    Tagwächter
                    1. 0

                      Nicht nur Suchmaschinen sondern auch Proxys

                      Tagwächter
                    2. 0

                      I'm a teapot

                      Der Martin
                      • menschelei
                      1. 0
                        Tagwächter
                        • humor
                        • menschelei
                        1. 0
                          Der Martin
                          1. 0
                            TS
                  2. 0
                    Der Martin
                    1. 1
                      Tagwächter
                      • suchmaschinen
              2. 0
                Matthias Apsel
    2. 0
      pl
    3. 0
      1unitedpower
  4. 0

    PHP: Unterseiten-URLs anpassen, interne Links nicht vergessen!

    TS
  5. 0

    Apache Directive FallbackResource

    TS
    • apache
    • php
    1. 0
      Tagwächter
      1. 0
        TS
        1. 1
          Google weiß alles
        2. 0
          pl

Hallo liebe Community, ich habe eine kleine Frage und zwar möchte ich meine Webseite angenehmer gestalten in dem ich die Unterseiten besser benenne.

Derzeit ist es so aufgebaut:
http://www.xxxxxxxx.de/index.php?page=aktuell
http://www.xxxxxxxx.de/index.php?page=kanzlei
usw.

Jedoch möchte ich es so haben:
http://www.xxxxxxxx.de/aktuell/
http://www.xxxxxxxx.de/hamburg/kanzlei/

Gibt es da im PHP Bereich eine Möglichkeit? Es handelt sich nur um eine Handvoll von Unterseiten. Es handelt sich um reine PHP Datein ohne CMS.

Liebe Grüße

Christoph

  1. Tach!

    Jedoch möchte ich es so haben:
    http://www.xxxxxxxx.de/aktuell/
    http://www.xxxxxxxx.de/hamburg/kanzlei/

    Gibt es da im PHP Bereich eine Möglichkeit?

    PHP allein bekommt das nicht hin. Der Webserver muss da ebenfalls mitarbeiten. Angenommen das ist der Apache, dann schreibt man alle Requests auf die index.php um. Das geht zum Beispiel so:

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule .* index.php [L]
    

    Innerhalb PHP musst du dann den relevanten Teil des Requests auswerten und entsprechend verzweigen. Alle Daten dazu findest du im Array $_SERVER. Mit phpinfo(INFO_VARIABLES); bekommst du die auch angezeigt. Die Angaben können von Server zu Server variieren. REQUEST_URI wird wohl das passende sein (also $_SERVER['REQUEST_URI']). Gegebenenfalls muss ein vorhandener Querystring abgeschnitten werden.

    dedlfix.

    1. Gegebenenfalls muss ein vorhandener Querystring abgeschnitten werden.

      Das machst Du doch gerade: (RewriteRule .* index.php [L])

      Sicher wolltest Du schreiben:

      Gegebenenfalls muss ein vorhandener Querystring mit übergeben werden.

      RewriteRule .* index.php [L,QSA]
      

      oder:

      RewriteRule .* index.php [L,qsappend]
      

      oder spezifischer:

      
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      
      # http[s]://server/ort/seite/ , http[s]://server/ort/seite
      RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
      
      # http[s]://server/seite/ , http[s]://server/seite
      RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
      

      Oder halt gleich so.

      1. Hallo und guten Abend,

        Gegebenenfalls muss ein vorhandener Querystring abgeschnitten werden.

        Das machst Du doch gerade: (RewriteRule .* index.php [L])

        Das hatte ich auch so gesehen...

        Gegebenenfalls muss ein vorhandener Querystring mit übergeben werden.

        RewriteRule .* index.php [L,QSA]
        

        Muss man das L hier schreiben, oder kann man es auch weglassen? Da ich nur die eine RwriteRule am Ende habe, habe ich es immer weggelassen.

        oder spezifischer:

        
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        
        # http[s]://server/ort/seite/ , http[s]://server/ort/seite
        RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
        
        # http[s]://server/seite/ , http[s]://server/seite
        RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
        

        Das wollte Christoph mMn aber gerade umgekehrt. Er hat zur Zeit ein System, das auf "?ort=a&page=b" reagiert und möchte, dass es nun von außen auf "php /ort/seite" hört. Innen muss er aber die Daten vermutlich noch in der alten Form verarbeiten.

        Viel wichtiger ist dann aber, dass er die vom System zu sendenden (Response) Links auch in die neue Form bringt.

        Grüße
        TS

        --
        es wachse der Freifunk
        http://freifunk-oberharz.de
        1. RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          
          # http[s]://server/ort/seite/ , http[s]://server/ort/seite
          RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
          
          # http[s]://server/seite/ , http[s]://server/seite
          RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
          

          Das wollte Christoph mMn aber gerade umgekehrt.

          Nö. Genau so... der Request http://server/ort/seite/ soll nach Ankunft auf dem Server zu http://server/index.php?ort=Hamburg&page=Kanzlei umgebaut werden.

          Viel wichtiger ist dann aber, dass er die vom System zu sendenden (Response) Links auch in die neue Form bringt.

          Naja. Fingerübung.

          <?php
          ob_start(); # Ausgaben speichern
          header( 'Content-Type: text/plain; charset=utf-8' ); # Nur für den Test!
           
          #... Testseite "bauen";
          ########
          echo <<<EOT
          <ul>
              <li><a href="https://server/index.php?page=impressum">Impressum</a></li>
              <li><a href="http://server/index.php?page=impressum">Impressum 2</a></li>
              <li><a href="/index.php?page=impressum">Impressum</a></li>
              <li><a href="https://server/index.php?ort=Hamburg&page=Kanzlei">Wir in Hamburg</a></li>
              <li><a href="http://server/index.php?ort=Hamburg&page=Kanzlei">Wir in Hamburg 2</a></li>
              <li><a href="/index.php?ort=Hamburg&page=Kanzlei">Wir in Hamburg 3</a></li>
              <li><a href="https://server/index.php?page=Kanzlei&ort=Hamburg">Wir in Hamburg 4</a></li>
              <li><a href="http://server/index.php?page=Kanzlei&ort=Hamburg">Wir in Hamburg 5</a></li>
              <li><a href="/index.php?page=Kanzlei&ort=Hamburg">Wir in Hamburg 6</a></li>
          </ul>
          EOT;
          ########
          
          $out = ob_get_contents(); # Seite aus Speicher holen
          ob_clean(); # Speicher löschen, sonst wird der nochmals ausgegeben!
          
          #Ein paar müde Ersetzungen:
          
          $s[] = 'https://server';
          $s[] = 'http://server';
          
          $out = str_replace($s, '', $out);
          
          $s = array();
          
          $s[] = '/index.php\?ort=(.*)\&page=(.*)(["\'])';
          $r[] = '/\1/\2/\3';
          
          $s[] = '/index.php\?page=(.*)\&ort=(.*)(["\'])';
          $r[] = '/\2/\1/\3';
          
          $s[] = '/index.php\?page=(.*)(["\'])';
          $r[]='/\1/\2';
          
          
          for ( $i=0 ; $i < count($s) ; $i++ ) {
              $s[$i] = '#' . str_replace('#', '\#', $s[$i]) . '#'; # Begrenzer für Regex!
              $out = preg_replace( $s[$i] , $r[$i] , $out);
          }
          
          echo $out;
          

          Ausgabe:

          <ul>
              <li><a href="/impressum/">Impressum</a></li>
              <li><a href="/impressum/">Impressum 2</a></li>
              <li><a href="/impressum/">Impressum</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg 2</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg 3</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg 4</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg 5</a></li>
              <li><a href="/Hamburg/Kanzlei/">Wir in Hamburg 6</a></li>
          </ul>
          
      2. Tach!

        Gegebenenfalls muss ein vorhandener Querystring abgeschnitten werden.

        Das machst Du doch gerade: (RewriteRule .* index.php [L])

        Sicher wolltest Du schreiben:

        Gegebenenfalls muss ein vorhandener Querystring mit übergeben werden.

        Nein, das war schon das, was ich schreiben wollte. Das bezog sich auf die Behandlung in PHP, denn da stört er beim Auswerten der URL meistens. Und natürlich möchte man auch, dass er übrhaupt erstmal zum PHP hin durchdringt. Also muss zusätzlich noch zu meiner RewriteRule ...

        RewriteRule .* index.php [L,QSA]
        

        ... das QSA angehängt werden.

        oder spezifischer:

        
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        
        # http[s]://server/ort/seite/ , http[s]://server/ort/seite
        RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
        
        # http[s]://server/seite/ , http[s]://server/seite
        RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
        

        Nö, so will ich das nicht propagieren. Das sieht man zwar öfter, dass man in der RewriteRule die Pfade gleich zerlegt, aber das ist recht unflexibel, weil man da genau festlegen muss, wieviele Bestandteile man haben möchte. Oder man schreibt sich entsprechend viele Regeln. Deswegen schreibe ich generell nur .* auf die index.php um und werte REQUEST_URI oder was ähnlich passendes nur in PHP aus.

        dedlfix.

        1. oder spezifischer

          Nö, so will ich das nicht propagieren. [...] Deswegen schreibe ich generell nur .* auf die index.php um und werte REQUEST_URI oder was ähnlich passendes nur in PHP aus.

          Deswegen schrieb ich: "spezifischer" und nicht etwa: "besser".

          Immerhin überlasse ich ja das Erkennen und Zerlegen in meiner geschmähten, aber funktionierenden und auch nicht schmutzigen Lösung - so wie Du es ebenfalls bevorzugst - dem Skript. Genau nur dann wenn dieses nicht verändert werden soll müssen die Regexe halt so spezifisch wie gezeigt "gebaut" werden. Das dabei, wie von Dir dargestellt, die Flexibilität ohne Not den Bach runter geht ist RICHTIG.

      3. Hi,

        
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        
        # http[s]://server/ort/seite/ , http[s]://server/ort/seite
        RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
        
        # http[s]://server/seite/ , http[s]://server/seite
        RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
        

        soweit mir bekannt gelten die RewriteCond nur für die erste nachfolgende RewriteRule, nicht für mehrere.

        Aus der Apache-Doku:
        The RewriteCond directive defines a rule condition. One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met.

        Die zweimalige Verwendung des Singulars deute ich so, daß nur die erste RewriteRule nach den RewriteConds von diesen RewriteConds betroffen ist.

        Die Bedingungen müßten daher m.E. wiederholt werden.

        Oder täusche ich mich da?

        cu,
        Andreas a/k/a MudGuard

        1. Die Bedingungen müßten daher m.E. wiederholt werden.

          Oder täusche ich mich da?

          Nein. Du hast Recht! Ich hatte das in der Verärgerung über diesen Mist übersehen.

          Das muss so aussehen:

          ### .htaccess
          # http[s]://server/ort/seite/ , http[s]://server/ort/seite
          RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          # Vorsicht! Nebenbedingungen (FollowSymlinks erlaubt? Nur dann auch):
          RewriteCond %{REQUEST_FILENAME} !-l 
          RewriteRule ^(.*)/(.*)/{0,1}$ index.php?ort=$1&page=$2 [L,QSA]
          
          # http[s]://server/seite/ , http[s]://server/seite
          RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          # Vorsicht! Nebenbedingungen (FollowSymlinks erlaubt? Nur dann auch):
          RewriteCond %{REQUEST_FILENAME} !-l 
          RewriteRule ^/(.*)/{0,1}$     index.php?page=$1 [L,QSA]
          

          FollowSymlinks

  2. Hallo und gute Nacht Christoph

    Hallo liebe Community, ich habe eine kleine Frage und zwar möchte ich meine Webseite angenehmer gestalten in dem ich die Unterseiten besser benenne.

    Derzeit ist es so aufgebaut:
    http://www.xxxxxxxx.de/index.php?page=aktuell
    http://www.xxxxxxxx.de/index.php?page=kanzlei
    usw.

    Jedoch möchte ich es so haben:
    http://www.xxxxxxxx.de/aktuell/
    http://www.xxxxxxxx.de/hamburg/kanzlei/

    Gibt es da im PHP Bereich eine Möglichkeit? Es handelt sich nur um eine Handvoll von Unterseiten. Es handelt sich um reine PHP Datein ohne CMS.

    Das geht, indem Du alle Requests auf die index.php umleitest, für die es keine echten Dateien gibt.

    # .htaccess
    RewriteEngine on
    RewriteBase /
    
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l
    
    RewriteRule .* index.php/$1 [QSA]
    
    

    und in der index-php dann die pathinfo auswertest anstelle der Get-parameter

    Dazu zerlegst Du Dir, wenn vorhanden, $_SERVER['REDIRECT_URL']

    Grüße
    TS

    --
    es wachse der Freifunk
    http://freifunk-oberharz.de
    1. Das geht, indem Du alle Requests auf die index.php umleitest, für die es keine echten Dateien gibt.

      # .htaccess
      RewriteEngine on
      RewriteBase /
      
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteCond %{REQUEST_FILENAME} !-l
      
      RewriteRule .* index.php/$1 [QSA]
      
      

      Oder einfach

      RewriteRule !\.(wav|zip|cgi|css|jpg|js|gif|ico|pac|png|htm|bin|pdf|nph)$ /cgi-bin/fw.cgi [L]
      

      Dazu zerlegst Du Dir, wenn vorhanden, $_SERVER['REDIRECT_URL']

      Muss nicht zerlegt werden. Mit REDIRECT_URL gehts direkt ab in die RoutingTable -- Spalte 1(URL). Alles Weitere: Parameter im Request, Message-Body im Request, Aktionen, dynamische Inhalte.... regelt die an den URL gebundene Klasse.

      MfG

      1. Hallo und guten Morgen,

        Das geht, indem Du alle Requests auf die index.php umleitest, für die es keine echten Dateien gibt.

        # .htaccess
        RewriteEngine on
        RewriteBase /
        
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteCond %{REQUEST_FILENAME} !-l
        
        RewriteRule .* index.php/$1 [QSA]
        
        

        Oder einfach

        RewriteRule !\.(wav|zip|cgi|css|jpg|js|gif|ico|pac|png|htm|bin|pdf|nph)$ /cgi-bin/fw.cgi [L]
        

        Dazu zerlegst Du Dir, wenn vorhanden, $_SERVER['REDIRECT_URL']

        Muss nicht zerlegt werden. Mit REDIRECT_URL gehts direkt ab in die RoutingTable -- Spalte 1(URL). Alles Weitere: Parameter im Request, Message-Body im Request, Aktionen, dynamische Inhalte.... regelt die an den URL gebundene Klasse.

        Da vermisse ich den Modifier für Case insensitive.

        Grüße
        TS

        --
        es wachse der Freifunk
        http://freifunk-oberharz.de
        1. moin,

          Oder einfach

          RewriteRule !\.(wav|zip|cgi|css|jpg|js|gif|ico|pac|png|htm|bin|pdf|nph)$ /cgi-bin/fw.cgi [L]
          

          Dazu zerlegst Du Dir, wenn vorhanden, $_SERVER['REDIRECT_URL']

          Muss nicht zerlegt werden. Mit REDIRECT_URL gehts direkt ab in die RoutingTable -- Spalte 1(URL). Alles Weitere: Parameter im Request, Message-Body im Request, Aktionen, dynamische Inhalte.... regelt die an den URL gebundene Klasse.

          Da vermisse ich den Modifier für Case insensitive.

          Ganz bestimmt vermisse ich den nicht.

          Tschitrakarna

          1. moin,

            Da vermisse ich den Modifier für Case insensitive.

            Ganz bestimmt vermisse ich den nicht.

            Naja. Es ist kein "Modifier" sondern ein "RewriteRule-Flag". Versuch einfach nett zu bleiben, denn genau solche "auf Konflikt gedrehte Belehrungen" kommen nicht gut an.

  3. http://www.xxxxxxxx.de/hamburg/kanzlei/

    Eine weitere, wenig beachtete Möglichkeit besteht darin mit

    ErrorDocument 404 /index.php
    

    in der Serverkonfiguration (oft: .htaccess) auf die index.php verweisen und dann $_SERVER['REQUEST_URI'] mit explode() zu zerlegen:

    Vorliegend würde ein Aufruf von http://www.xxxxxxxx.de/hamburg/kanzlei/ dazu führen, dass in $_SERVER['REQUEST_URI'] dann '/hamburg/kanzlei/' steht.

    Diesen also etwa wie folgt behandeln:

    $str = trim($_SERVER['REQUEST_URI'], '/'); 
    $str = preg_replace( '#//+#' , '/' , $str ); # Für eventuelle '//' (Fehleingaben)
    

    behandeln. Das Ergebnis wäre 'hamburg/kanzlei'.

    Dann explode:

    $ar = explode('/', $str);
    

    Tja. Und dann noch etwas wie:

    if ( 1 < count( $ar ) ) {
       $item = array_pop( $ar );
       $arKategorien = $ar;
       require_once( $_SERVER['DOCUMENT_ROOT'] . '/lib/getDocument.php' );
       getDocument($item, $arKategorien);
    } else {
       $arKategorien = false;
       $item = $ar[0];
       require_once( $_SERVER['DOCUMENT_ROOT'] . '/lib/getDocument.php' );
       getDocument($item, $arKategorien);
    } 
    

    lib/getDocument.php zum Erzeugen der Webseite bzw. der Suche nach dem Dokument enthalten.

    Lauffähiges Testskript mit Berücksichtigung der alten Adressierung:

    <?php
    /**
    * @filename: /index.php
    **/
    
    ### Testwerte:
    #$_SERVER['REQUEST_URI'] = '/';
    #$_GET['page'] = 'Kanzlei';
    
    # $_SERVER['REQUEST_URI'] = '/impressum/';
    # $_SERVER['REQUEST_URI'] = 'Hamburg/Kanzlei/';
    # $_SERVER['REQUEST_URI'] = '/Hamburg/Kanzlei';
    # $_SERVER['REQUEST_URI'] = '/Rio//Kanzlei';
    $_SERVER['REQUEST_URI'] = '/München/Kanzlei//Anwälte/Andreas+Mustermann';
    ###
    
    ob_start();
    
    $str = trim($_SERVER['REQUEST_URI'], '/');
    $str = preg_replace( '#//+#' , '/' , $str ); # Für eventuelle '//' (Fehleingaben)
    
    $ar = explode('/', $str);
    
    if (! isset($_GET['page']) ) {
        if ( 1 < count( $ar ) ) {
            $item = array_pop( $ar );
            $arKategorien = $ar;
            #require_once( $_SERVER['DOCUMENT_ROOT'] . '/lib/getDocument.php' );
            getDocument($item, $arKategorien);
        } else {
            $arKategorien = false;
            $item = $ar[0];
            #require_once( $_SERVER['DOCUMENT_ROOT'] . '/lib/getDocument.php' );
            getDocument($item, $arKategorien);
        }
    } else {
        header( 'Status: 301 Document moved' );
        header( 'Location: /' . rawurlencode( $_GET['page'] ) );
        echo 'Location: /' . rawurlencode( $_GET['page'] ) , "\n";
    }
    exit;
    
    function getDocument( $item , $arKategorien ) {
        header( 'Content-Type: text/plain; charset=utf-8' );
        echo 'Item: "' . urldecode( $item ) . '"', "\n";
        echo 'Kategorien: '; print_r( $arKategorien );
        echo "\n";
    }
    
    1. Eine "Nicht hilfreich"-Bewertung offensichtlich funktionierenden Zeugs ohne Begründung ist selbst "nicht hilfreich".

      Die andere Nachricht ist, denke ich, auch beim Adressat angekommen.

      1. Tach!

        Eine "Nicht hilfreich"-Bewertung offensichtlich funktionierenden Zeugs ohne Begründung ist selbst "nicht hilfreich".

        Die Bewertung sagt lediglich "negativ" oder "positiv" aus. Weas auch immer der Bewerter im Sinn hatte, es muss nicht zwingend wegen "(nicht) hilfreich" vergeben worden sein. (Hilfreich / nicht hilfreich war eine Zeit lang im alten Forum die Bedeutung der Bewertung. Da sich aber oftmals die Bewerter nicht daran orientierten, wurde die sie wieder verallgemeinert.)

        Die andere Nachricht ist, denke ich, auch beim Adressat angekommen.

        Ist bei dir auch etwas angekommen?

        dedlfix.

        1. Die Bewertung sagt lediglich "negativ" oder "positiv" aus.

          Mag sein. Aber selbst wenn eine funktionierende Lösung nur mit "negativ" bewertet wird, dann sollte man das durchaus begründen. Sonst ist das "nicht hilfreich".

          Ist bei dir auch etwas angekommen?

          Ja. Ein Mod hat mit dem anderen geredet und ihm gesagt, dass er übertreibt und dann die Sperre des Beitrags wieder aufgehoben.

          1. Tach!

            Ja. Ein Mod hat mit dem anderen geredet und ihm gesagt, dass er übertreibt und dann die Sperre des Beitrags wieder aufgehoben.

            Es war aus unserer Sicht eher anders. Nachdem du deine Übertreibung und Provokation aufgegeben hattest, konnten wie das zwangsweise Einhalten der Charta wieder beenden.

            dedlfix.

            1. Es war aus unserer Sicht eher anders. Nachdem du deine Übertreibung und Provokation aufgegeben hattest, konnten wie das zwangsweise Einhalten der Charta wieder beenden.

              Oh! Das stammt ja nahezu wörtlich aus dem "Handbuch für politische Redner und Pressesprecher" von Jewgeni Unwarnikov.

              1. Tach!

                Es war aus unserer Sicht eher anders. Nachdem du deine Übertreibung und Provokation aufgegeben hattest, konnten wie das zwangsweise Einhalten der Charta wieder beenden.

                Oh! Das stammt ja nahezu wörtlich aus dem "Handbuch für politische Redner und Pressesprecher" von Jewgeni Unwarnikov.

                Toll, nicht? Da hab ich auch mit Liebe ein Weilchen dran gefeilt, bis es so hübsch formuliert bekommen habe. ;)

                dedlfix.

      2. Ein Test fehlte noch:

        http://server/München/Kanzlei//Anwälte/Andreas+Mustermann

        Das urldecode für den Array sollte die Funktion getDocument natürlich noch vornehmen...

      3. Tach!

        Eine "Nicht hilfreich"-Bewertung offensichtlich funktionierenden Zeugs ohne Begründung ist selbst "nicht hilfreich".

        Nachdem ich nun wieder den Kopf für technische Dinge freihabe, gebe ich mal meine Antwort. Die muss nicht unbedingt mit der des Bewerter übereinstimmen.

        Die Idee, mithilfe des ErrorDocument ein Rewriting vorzunehmen, sieht auf den ersten Blick recht clever aus. Und das gewünschte Ziel ist damit auch zu erreichen. Vielleicht sogar ohne negative Nebenwirkungen. Dazu gleich mehr. Aus semantischer Sicht ist sie aber ziemlich daneben. Jemand, der das das erste Mal und ohne Erklärung sieht, sieht "ErrorDocument" und denkt sich vermutlich, dass das was mit Fehlerbehandlung zu tun hat. Und sucht dann weiter nach der Behandlung der fehlerfreien Requests. Für intuitives Verstehen ist so eine Negation der Negativbehandlung nicht unbedingt geeignet.

        Nun noch zu den Nebenwirkungen. Du hast vergessen, den Statuscode auf 200 zu ändern. Selbst wenn man das noch nachzieht, wie sieht es mit dem Error-Log aus? Bleibt das unberührt? Falsche Einträge behindern nur die Sicht auf die wirklichen Fehler.

        dedlfix.

        1. Dazu gleich mehr. Aus semantischer Sicht ist sie aber ziemlich daneben. Jemand, der das das erste Mal und ohne Erklärung sieht, sieht "ErrorDocument" und denkt sich vermutlich, dass das was mit Fehlerbehandlung zu tun hat.

          Ja. Aber wenn der "Admin" oder "Webdesigner" weiß, was die Konditionen -f und -d machen, dann weiß er das erst recht. Trefflicher wäre womöglich "router.php" statt "index.php". Wenn der "Admin" oder "Webdesigner" DAS dann immer noch nicht sieht sollte er ein paar Kurse bei mir belegen und sich solange selbst suspendieren.

          Vorteil meines Vorgehens ist wohl, dass die Funktion des Aufrufens eines Error-Dokuments wohl sogar etwas performanter sein wird, weil diese im Apache "fest verdrahtet" ist. Die Konditionen muss er erst lesen und verarbeiten.

          Nun noch zu den Nebenwirkungen. Du hast vergessen, den Statuscode auf 200 zu ändern. Selbst wenn man das noch nachzieht,

          Ein solcher "Router" muss sowieso den Statuscode setzen. Was, wenn er kein "Dokument" findet? Ganz geschickte Burschen werten sogar header-requests aus und schauen nach dem E-Tag und ob was passendes serverseitig gecacht oder verändert wurde - müssten also auch einen 304er senden können.

          wie sieht es mit dem Error-Log aus? Bleibt das unberührt?

          Bei meinem ist das so, also keine Einträge. Die stehen mit Status 404 im access.log. Ich habe die Original-Konfiguration (Apache 2.4, Debian 8) belassen.

          Falsche Einträge behindern nur die Sicht auf die wirklichen Fehler.

          So ist es. Zu viele auch.

          1. Tach!

            Aus semantischer Sicht ist sie aber ziemlich daneben. Jemand, der das das erste Mal und ohne Erklärung sieht, sieht "ErrorDocument" und denkt sich vermutlich, dass das was mit Fehlerbehandlung zu tun hat.

            Ja. Aber wenn der "Admin" oder "Webdesigner" weiß, was die Konditionen -f und -d machen, dann weiß er das erst recht. Trefflicher wäre womöglich "router.php" statt "index.php". Wenn der "Admin" oder "Webdesigner" DAS dann immer noch nicht sieht sollte er ein paar Kurse belegen und sich solange selbst suspendieren.

            Mitunter läuft der Kram unbeachtet vor sich hin und dann plötzlich gibts ein Problem. Und wie das sop ist, immer dann, wenn man grad Stress hat. Ich habe ja seblst nichts gegen das Mitdenken, im Gegenteil. Aber in dem Fall sollte man das System schnell durchschauen können.

            Vorteil meines Vorgehens ist wohl, dass die Funktion des Aufrufens eines Error-Dokuments wohl sogar etwas performanter sein wird, weil diese im Apache "fest verdrahtet" ist. Die Konditionen muss er erst lesen und verarbeiten.

            Übrigens - das vergesse ich auch immer wieder gern, weil es in meiner Konstellation ein paar Nebenwirkungen hatte, und ich es deswegen nicht verwende - gibt es schon eine Weile die Direktive FallbackResource im Apachen. Die macht im Primzip genau dasselbe wie dein ErrorDocument, nur eben mit ordentlicher Geradeaus-Semantik. Probier die doch mal!

            dedlfix.

            1. Übrigens - das vergesse ich auch immer wieder gern, weil es in meiner Konstellation ein paar Nebenwirkungen hatte, und ich es deswegen nicht verwende - gibt es schon eine Weile die Direktive FallbackResource im Apachen.

              Na sowas löbliches aber auch. Kannte schon der Vater (2.2), dem Großvater(2.0) hats laut doc noch gefehlt. Danke für den Tipp. Technisch wird der indigene Server dann den Status nicht per Default auf 404 festsetzen, der Rest ist ein Alias.

              Die macht im Primzip genau dasselbe wie dein ErrorDocument, nur eben mit ordentlicher Geradeaus-Semantik

              Guter Tipp! THX!

              Probier die doch mal!

              [x] ist online und geht natürlich

              1. Übrigens - das vergesse ich auch immer wieder gern, weil es in meiner Konstellation ein paar Nebenwirkungen hatte, und ich es deswegen nicht verwende - gibt es schon eine Weile die Direktive FallbackResource im Apachen.

                Na sowas löbliches aber auch. Kannte schon der Vater (2.2), dem Großvater(2.0) hats laut doc noch gefehlt. Danke für den Tipp. Technisch wird der indigene Server dann den Status nicht per Default auf 404 festsetzen, der Rest ist ein Alias.

                Die macht im Primzip genau dasselbe wie dein ErrorDocument, nur eben mit ordentlicher Geradeaus-Semantik

                Guter Tipp! THX!

                Probier die doch mal! [x] ist online und geht natürlich

                Nein. "FallbackResource" geht nicht wirklich. Bei einer URL mit GET-Params versagt das Ding verifizierbar. (Verbindung wird beendet). Zurück zu ErrorDocument404.

            2. Hallo und guten Morgen,

              Übrigens - das vergesse ich auch immer wieder gern, weil es in meiner Konstellation ein paar Nebenwirkungen hatte, und ich es deswegen nicht verwende - gibt es schon eine Weile die Direktive FallbackResource im Apachen. Die macht im Primzip genau dasselbe wie dein ErrorDocument, nur eben mit ordentlicher Geradeaus-Semantik. Probier die doch mal!

              Ich erinnere mich noch gut an eine heftige Diskussion zum "false 404". Das muss so ca. 2011 oder 2012 gewesen sein. Im Archiv kann ich das aber leider nicht finden. Dabei war der Thread recht länglich geworden.

              Hat sich da an der Meinung seitdem soviel geändert?

              Grüße
              TS

              --
              es wachse der Freifunk
              http://freifunk-oberharz.de
              1. Ich erinnere mich noch gut an eine heftige Diskussion zum "false 404". Das muss so ca. 2011 oder 2012 gewesen sein. Im Archiv kann ich das aber leider nicht finden. Dabei war der Thread recht länglich geworden.

                Hat sich da an der Meinung seitdem soviel geändert?

                Natürlich ist es falsch einen 404er zu senden.

                Aber:

                Mit http_response_code(200); kann man einen anderen Status nach Belieben senden. Zugleich kann die als "Error-Dokument" eingestellte index.php (oder besser: router.php):

                Und wenn man jetzt nicht vergisst den Statuscode entsprechend zu ändern, dann ist eigentlich alles in Ordnung. Auf der Clientseite ist davon nichts zu spüren.

                1. Hallo und guten Morgen,

                  Ich erinnere mich noch gut an eine heftige Diskussion zum "false 404". Das muss so ca. 2011 oder 2012 gewesen sein. Im Archiv kann ich das aber leider nicht finden. Dabei war der Thread recht länglich geworden.

                  Hat sich da an der Meinung seitdem soviel geändert?

                  Natürlich ist es falsch einen 404er zu senden.

                  Da hat sich die Meinung ja jetzt um 180° gedreht!

                  In der damaligen Diskussion bin ich dafür gescholten worden, dass ich ein Fallback-Dokument mit 200 ausgeliefert habe. Dass das irgendwo anecken könnte, hat Google in seinen Webmastertools angezeigt. Die haben gemerkt, dass alle Requests, die nicht vorhanden waren, mit einem Fallback-Dokument und 200 beantwortet wurden und wollten Fallback und 404 haben. Das FB + 200 nennen sie "false 404 Error".

                  Ich weiß nicht, warum ich die Diskussion im Archiv nicht mehr finden kann.

                  Grüße
                  TS

                  --
                  es wachse der Freifunk
                  http://freifunk-oberharz.de
                  1. Das FB + 200 nennen sie "false 404 Error".

                    Ein "false 404 Error" wäre aber eher wenn ein Dokument gefunden und angezeigt wird, aber dennoch der Statuscode 404 gesendet wird - z.B. weil der "Webmaster" so wie von mir vorgeschlagen das Error-Handling nutzt um den Router zu starten - und dann aber den Statuscode nicht setzt. Ein Suchergebnis oder Vorschläge für weiteres Vorgehen als Reaktion auf eine falsche Adresse sind aber kein "Dokument" im Sinne der Suchmaschine, weil man (auch ein Dritter) diese böswillig mit falschen Adressen an den Rand des Wahnsinns treiben könnte.

                    Da hat sich die Meinung ja jetzt um 180° gedreht!

                    Nein, denn das ist richtig so:

                    In der damaligen Diskussion bin ich dafür gescholten worden, dass ich ein Fallback-Dokument mit 200 ausgeliefert habe. Dass das irgendwo anecken könnte, hat Google in seinen Webmastertools angezeigt. Die haben gemerkt, dass alle Requests, die nicht vorhanden waren, mit einem Fallback-Dokument und 200 beantwortet wurden und wollten Fallback und 404 haben.

                    Also noch mal. So ein Router sollte den Statuscode ohnehin auswählen und senden:

                    • Dokument wird aufgrund der Daten (Adresse) eindeutig gefunden und angezeigt -> Status 200 -> Die Suchmaschine merkt sich Adresse und Dokument wenn kein Meta-Tag (oder eine robots.txt) anderes propagiert.
                    • Unterfall hierzu: Dokument wird aufgrund der Daten (Adresse) eindeutig gefunden, der Agent hat aber einen ETag gesendet und es wurde festgestellt, dass dessen Version noch gültig ist -> Status 304 und KEIN Dokument -> Falls eine Suchmaschine mal einen ETag senden sollte wird die das auch gut finden und alles lassen wie es ist.
                    • Neue Adresse des verzogenen Dokumentes ist bekannt und der Agent per Location-Header zu dieser geschickt -> Status 301 -> Suchmaschinen merken sich die neue Adresse als die des Dokuments und vergessen die alte.
                    • keine eindeutige Adresse, kein Verzug bekannt, deshalb Suche durchgeführt und/oder Vorschläge angezeigt -> Status 404 -> Suchmaschine wird Adresse aus falsch geschriebenen Link nicht speichern.

                    Freilich können auch alle anderen Fälle eintreten - sogar ein 418er den ich irgendwo und irgendwann mal verwendet habe um auf den Versuch, Spam einzutragen, zu reagieren. Inzwischen gibts da aber auch den 200er. Ich muss ja den Spammer nicht informieren.

                    1. Noch ein Hinweis: Es gibt ja nicht nur Suchmaschinen sondern auch Proxys. Die reagieren aber ähnlich.

                    2. Hallo,

                      Freilich können auch alle anderen Fälle eintreten - sogar ein 418er den ich irgendwo und irgendwann mal verwendet habe um auf den Versuch, Spam einzutragen, zu reagieren.

                      YMMD! :-)

                      So long,
                       Martin

                      --
                      Es gibt eine Theorie, die besagt, dass das Universum augenblicklich durch etwas noch Komplizierteres und Verrücktes ersetzt wird, sobald jemand herausfindet, wie es wirklich funktioniert. Es gibt eine weitere Theorie, derzufolge das bereits geschehen ist.
                      - (frei übersetzt nach Douglas Adams)
                      1. Es gibt eine Theorie, die besagt, dass das Universum augenblicklich durch etwas noch Komplizierteres und Verrücktes ersetzt wird, sobald jemand herausfindet, wie es wirklich funktioniert. Es gibt eine weitere Theorie, derzufolge das bereits geschehen ist.

                        • (frei übersetzt nach Douglas Adams)

                        Das Buch kenne ich natürlich. Aber in meiner Kindheit habe ich mal viele Fehler angekreidet bekommen weil ich zu wenig Kommas gesetzt habe. Darauf hin habe ich ähnlich viele Kommas gesetzt wie in obigem Text. War wieder alles rot.

                        Ich habe mich dann damit abgefunden, dass ich und Frau Kommata keine gute Beziehung führen können.

                        1. Hallo,

                          Es gibt eine Theorie, die besagt, dass das Universum augenblicklich durch etwas noch Komplizierteres und Verrücktes ersetzt wird, sobald jemand herausfindet, wie es wirklich funktioniert. Es gibt eine weitere Theorie, derzufolge das bereits geschehen ist.

                          • (frei übersetzt nach Douglas Adams)

                          Das Buch kenne ich natürlich. Aber in meiner Kindheit habe ich mal viele Fehler angekreidet bekommen weil ich zu wenig Kommas gesetzt habe. Darauf hin habe ich ähnlich viele Kommas gesetzt wie in obigem Text. War wieder alles rot.

                          tja, es gilt eben wie so oft im Leben: Man muss ein gesundes Mittelmaß treffen.
                          Übrigens bin ich nach nochmaligem kritischem Hinsehen immer noch überzeugt, dass im oben zitierten Text die Kommas (meinetwegen auch Kommata) in Anzahl und Position richtig gesetzt sind.

                          Ich habe mich dann damit abgefunden, dass ich und Frau Kommata keine gute Beziehung führen können.

                          Ich habe seit der Grundschule den Vorteil, dass ich in Deutsch (Rechtschreibung, Zeichensetzung, Grammatik) in >99% der Zweifelsfälle gefühlsmäßig richtig liege, meine Ansicht aber nicht immer anhand der Regeln begründen kann. "Des isch halt so."
                          In Englisch ging es mir später ähnlich.

                          So long,
                           Martin

                          --
                          Es gibt eine Theorie, die besagt, dass das Universum augenblicklich durch etwas noch Komplizierteres und Verrücktes ersetzt wird, sobald jemand herausfindet, wie es wirklich funktioniert. Es gibt eine weitere Theorie, derzufolge das bereits geschehen ist.
                          - (frei übersetzt nach Douglas Adams)
                          1. Hallo und guten Morgen,

                            Ich habe seit der Grundschule den Vorteil, dass ich in Deutsch (Rechtschreibung, Zeichensetzung, Grammatik) in >99% der Zweifelsfälle gefühlsmäßig richtig liege, meine Ansicht aber nicht immer anhand der Regeln begründen kann. "Des isch halt so."
                            In Englisch ging es mir später ähnlich.

                            Dann bist Du also sozusagen jetzt ein Postfaktotum ;-)

                            Grüße
                            TS

                            --
                            es wachse der Freifunk
                            http://freifunk-oberharz.de
                  2. Moin,

                    Ich erinnere mich noch gut an eine heftige Diskussion zum "false 404". Das muss so ca. 2011 oder 2012 gewesen sein. Im Archiv kann ich das aber leider nicht finden. Dabei war der Thread recht länglich geworden.

                    Hat sich da an der Meinung seitdem soviel geändert?

                    Natürlich ist es falsch einen 404er zu senden.

                    Da hat sich die Meinung ja jetzt um 180° gedreht!

                    nein, das denke ich nicht.

                    In der damaligen Diskussion bin ich dafür gescholten worden, dass ich ein Fallback-Dokument mit 200 ausgeliefert habe.

                    Dann verwechselst du möglicherweise etwas. Ich vermute, dass du eine Art Ersatz- oder Alternativinhalt geliefert hast, obwohl du den Client-Request nicht exakt bedienen konntest. In diesem Fall Status 200 zu senden, ist IMO nach wie vor verpönt. In dem Fall sollte, auch wenn man alternativen Inhalt bietet, der Status 404 sein, fallweise vielleicht auch 300. Oder eben 301, wenn eindeutig ist, was der Client will und man sicher sein kann, diese Ressource unter anderer Adresse zu haben.

                    Falsch ist IMO, den Status 200 zu senden, wenn man den Request nicht mit Sicherheit richtig bedienen kann.

                    Dass das irgendwo anecken könnte, hat Google in seinen Webmastertools angezeigt. Die haben gemerkt, dass alle Requests, die nicht vorhanden waren, mit einem Fallback-Dokument und 200 beantwortet wurden und wollten Fallback und 404 haben. Das FB + 200 nennen sie "false 404 Error".

                    Kann ich mir nur schwer vorstellen, denn der Client (also auch ein Google-Bot) kann den server-internen Fallback gar nicht erkennen.

                    So long,
                     Martin

                    --
                    Es gibt eine Theorie, die besagt, dass das Universum augenblicklich durch etwas noch Komplizierteres und Verrücktes ersetzt wird, sobald jemand herausfindet, wie es wirklich funktioniert. Es gibt eine weitere Theorie, derzufolge das bereits geschehen ist.
                    - (frei übersetzt nach Douglas Adams)
                    1. Kann ich mir nur schwer vorstellen, denn der Client (also auch ein Google-Bot) kann den server-internen Fallback gar nicht erkennen.

                      Naja. Doch. Aber nicht mit einem Request.

                      wenn es auf Grund einer automatisch, versehentlich oder böswillig erzeugten Linkwüste mit Links zu

                      • http://server/gibtsnicht
                      • http://server/gibtsesauchnicht
                      • http://server/gabesnochnie
                      • http://server/hamwanich
                      • ...

                      auf den Request hin eine nahezu identische Antwort (mit Stautus 200) gibt wie

                      Der Artikel "gibtsnicht" wurde nicht gefunden (pla, blubb) + ebenfalls identische Bestandteile (Header, Menü, Footer)

                      dann kann Google & Co. das mit einem Blick in den Speicher durchaus feststellen - nur eben nicht anhand des EINEN Requests und der EINEN Antwort. Die sind ja Meister der Statistik (messen sogar Antwortzeiten!) und alle Bestandteile der URL aus dem Dokument rauszufiltern und das Resultat mal durch MD5, SHA1 o.ä. zu jagen um mal nachzuschauen, wie viele Antworten von einem Server dann einen identischen Hash haben, wird Google sicher leicht fallen.

                      Ich würde es jedenfalls so machen.

              2. Hallo TS,

                Ich erinnere mich noch gut an eine heftige Diskussion zum "false 404". Das muss so ca. 2011 oder 2012 gewesen sein. Im Archiv kann ich das aber leider nicht finden. Dabei war der Thread recht länglich geworden.

                https://forum.selfhtml.org/self/2014/dec/7/welchen-http-status-senden/1626902#m1626902?

                Bis demnächst
                Matthias

                --
                Dieses Forum nutzt Markdown. Im Wiki erhalten Sie Hilfe bei der Formatierung Ihrer Beiträge.
    2. http://www.xxxxxxxx.de/hamburg/kanzlei/

      Eine weitere, wenig beachtete Möglichkeit besteht darin mit

      ErrorDocument 404 /index.php
      

      Zweckmäßig ist und das bietet sich ja an, für den Status 404 dasselbe Script einzusetzen, was ohnehin in die RoutingTable guckt. Somit ergibt sich eine einheitliche Response-Seite für diesen Status und falls nach Klassen geroutet wird, ist das dann class=NotFound -- da steht schon im Namen geschriebn wofür diese Klasse gut ist.

      in der Serverkonfiguration (oft: .htaccess) auf die index.php verweisen und dann $_SERVER['REQUEST_URI'] mit explode() zu zerlegen:

      Die Variable REDIRECT_URL (setzt der Server in mod_rewrite) muss nicht zerlegt werden. z.B.: "/hamburg/kanzlei/" steht da drin (ohne etwaigen query_string).

    3. Hallo,

      echo 'Location: /' . rawurlencode( $_GET['page'] ) , "\n";
      

      beim Umleiten sollte geprüft werden, ob die Ziel-URL vertrauenswürdig ist. Andernfalls öffnet man Türen für Phishing-Angriffe. Ein Angreifer könnte einen Link erzeugen, der dem Anschein nach auf deine Seite verweist, aber in Wirklichkeit zur Phishing-Seite führt.

  4. Hallo und guten Tag,

    noch ein Nachtrag, denn das wird immer gerne vergessen:

    in allen Dokumenten sollten als interne Verweise dann aber auch die neuen Links drinstehen. Die müssen also auch überarbeitet werden, denn diese werden ja primär von den Suchmaschinen referenziert.

    Grüße
    TS

    --
    es wachse der Freifunk
    http://freifunk-oberharz.de
  5. Hallo und gute Nacht,

    bei Verwendung der Apache-Directive FallbackResource (Achtung, engl. nur mit einem 's' in Resoruce) nützt Dir zur Zerlgung dann ein Blick mit

    $_purl = parse_url($_SERVER['REQUEST_URI']);
        echo htmlspecialchars(print_r($_purl, 1));  
    

    Die Query-Parameter, also alles was hnter dem '?' kommt, stehen dann auch in $_GET

    Grüße
    TS

    --
    es wachse der Freifunk
    http://freifunk-oberharz.de
    1. $_purl = parse_url($_SERVER['REQUEST_URI']);
          echo htmlspecialchars(print_r($_purl, 1));  
      

      Die Query-Parameter, also alles was hnter dem '?' kommt, stehen dann auch in $_GET

      Mein, nicht "dann" sondern schon vorher. Genauer gesagt ganz ohne parse_url()...

      1. Hallo und gute Nacht,

        $_purl = parse_url($_SERVER['REQUEST_URI']);
            echo htmlspecialchars(print_r($_purl, 1));  
        

        Die Query-Parameter, also alles was hnter dem '?' kommt, stehen dann auch in $_GET

        Mein, nicht "dann" sondern schon vorher. Genauer gesagt ganz ohne parse_url()...

        Darauf würde ich mich nie verlassen, ohne zu überprüfen, wie mein Webserver das genau handhabt. Wenn man nicht selber Herr über den Host ist, sondern auf Strato oder andere angewiesen ist, dann tauchen da im Environment manchmal ganz neue Paremeter auf oder es fehlen welche. Ich erinnere da nur an die Misere mit der Authentifizierung über .htaccess!

        
        Ich hätte da aber noch andere Fragen an Dich, die nicht in diesen Thread passen...  
        Iptables und separate Logsatei für LOG usw.  
        
        
        
          
        Grüße  
        TS
        
        -- 
        es wachse der Freifunk   
        
        <http://freifunk-oberharz.de>
        
        
        1. $_purl = parse_url($_SERVER['REQUEST_URI']);

          Die Query-Parameter, also alles was hnter dem '?' kommt, stehen dann auch in $_GET Mein, nicht "dann" sondern schon vorher. Genauer gesagt ganz ohne parse_url()... Darauf würde ich mich nie verlassen, ohne zu überprüfen, wie mein Webserver das genau handhabt.

          Also es gibt zwei Fälle. Wenn in $_SERVER['REQUEST_URI'] was auswertbares steht, dann steht das Ergebnis dieser Auswertung auch in $_GET. Diese Daten sind da oder nicht und den Job, diese nach $_GET zu schaufeln (und ein wenig mit Tricks wie urldecode() zu zaubern), den macht PHP. Strato richtet zwar auf den Servern MANCHES höchst ungewöhnlich, unerwartet und fragwürdig ein - aber DAS gewiss nicht weil die Bereitstellung der Daten in $_GET, $_POST, $_COOKIE, $_SESSION einfach zu elementar ist und der Kundendienst sich zu sehr verteuern würde.

          (Tagwächter a.k.a Google weiß alles)

        2. Hallo und gute Nacht,

          $_purl = parse_url($_SERVER['REQUEST_URI']);
              echo htmlspecialchars(print_r($_purl, 1));  
          

          Die Query-Parameter, also alles was hnter dem '?' kommt, stehen dann auch in $_GET

          Mein, nicht "dann" sondern schon vorher. Genauer gesagt ganz ohne parse_url()...

          Darauf würde ich mich nie verlassen, ohne zu überprüfen, wie mein Webserver das genau handhabt.

          Das legt die CGI/1.1 Spezifikation fest wie ein Webserver das zu handhaben hat -- falls er dafür konfiguriert ist. So besteht der Gateway eben nicht nur aus STDIN/STDOUT sondern auch aus einer Reihe von Umgebungs-Variablen die ein für CGI/1.1 konfigurierter Webserver zu setzen hat. Und so kannst Du das auch prüfen.