nicht angemeldet
Hallo Mathias,
(Sorry, ist mir in den letzten Tagen etwas entflutscht, zu antworten)
Außer diesem hypothetischen »es könnte ja völlig kaputte und hirnrissige Clients geben« spricht m.E. praktisch nichts gegen GET.
Nun ja, es gibt ja Clients, die sich teilweise so verhalten, weswegen ich explizit nicht nur Bots, sondern Prefetch-Anwendungen erwähne, die schon Probleme gemacht haben.
Nur bei dynamischen, oft personalisierten, jedenfalls geschlossenen Webanwendungen gibt es überhaupt die »Nebeneffekte« auf dem Server. Wenn man auf solche Webanwendungen Robots loslässt, muss notwendigerweise etwas schiefgehen. Daher gibt es Authentifizierung, Identifizierung usw. und nicht jeder Robot bekommt URLs zu Gesicht, deren GET-Aufruf irgendwelche serverseitigen »Nebeneffekte« hat (wie z.B. das Löschen von Daten).
Und gerade Prefetch-Erweiterungen sind nunmal (durch den Nutzer) authentifiziert, weil diese für diesen selbst agieren. Firefox' eingebauter Algorithmus erwartet zwar ein explizites Auszeichnen des zu prefetchenden Links durch den Webmaster, andere Prefetching-Erweiterungen sind da nicht so brav sondern fetchen alles, was nicht bei drei auf den Bäumen ist. Hier ärgert sich der Anbieter populärer Web-Anwendungen sehr über den GWA, weil sein Web-Framework stark auf GET-Aktionen ausgerichtet ist.
Zugegeben, die Anbieter von alles ladenden Prefetch-Erweiterungen machen teilweise Annahmen, was sie besser nicht laden sollten:
• Der Google Web Accelerator lädt keine Verweise mit Parametern.
• Fasterfox lädt nur „statische Seiten“, konkret orientiert es sich an der Dateiendung (*.html, *.jpg, *.etc)
Und auch wenn das relativ intelligente Annahmen im derzeitigen Web sind, kann man als Seitenanbieter dagegen verstoßen. RoR (in früheren Versionen und im Default) nutzt z.B. Parameter wie delete nicht im Parameter-Anteil der URI sondern im Pfad-Anteil. Usw. Diese Erweiterungen machen bestimmte Annahmen auf der Basis von HTTP (Beim GWA schon direkt in der Webmasters FAQ); als Anbieter von Web-Anwendungen erwidert man nun diese Annahmen entweder mit extra Code auf Serverseite, sperrt die Erweiterungen mit robots.txt oder HTTP-Header-Analyse aus oder erfüllt einfach die Annahmen von HTTP bei der Entwicklung. Letzteres erscheint mir einfach am entspanntesten, denn ansonsten ist das Aussperren von Prefetching ein Rennen, immer wenn ein neues solches Tool erscheint oder ein bestehendes seine Regeln ändert.
(Und wie schon woanders geschrieben: GET-Aktionen sind eine Basis für CSRF-Sicherheitslücken, weil man damit jemanden auf der Seite Berechtigtem das unbeabsichtigte Laden von verändernden Verweisen unterjubeln kann.)
Tim
Der Martin