Benutzerfreundliche URIs

Einleitung

Um das Gebiet der visuellen Gestaltung von Ressourcen für die Veröffentlichung im Web sind bereits eigene Berufsbilder entstanden. Vielfach bleibt jedoch unberücksichtigt, daß es sich bei den URIs der Ressourcen einer Website ebenfalls um eine Form der Benutzerschnittstelle handelt, deren Gestaltung bewußt und mit Bedacht erfolgen sollte.

Die Syntax von URIs wird in Uniform Resource Identifiers (URI): Generic Syntax spezifiziert. Während URIs mit verschiedensten Schemata Einsatz finden, konzentriert sich dieser Artikel auf URIs für das Schema HTTP, wie sie im Web zum Einsatz gelangen und wo sie von den meisten Menschen wahrgenommen werden.

Leitlinien und Hinweise zur Wahl sinnvoller URIs

Eigenschaften von URIs

Für das Verständnis der nachfolgend vorgestellten Leitlinien zur Gestaltung von URIs ist es notwendig, zwischen zwei Eigenschaften von URIs zu unterschieden:

Die Eigenschaften Persistenz und Kanonizität stehen nicht in direktem Zusammenhang zueinander. Dennoch kann die bedachtsame Wahl des kanonischen URIs es erleichtern, dessen Persistenz zu gewährleisten. Der Aufwand für die Konfiguration von URIs läßt sich verringern, indem eine Vielzahl an URIs zur Bezeichnung einer bestimmten Ressource vermieden wird. Zudem verbessert eine geschickte Auswahl von URIs deren Benutzbarkeit für den Menschen.

Der zur Garantie der beiden Eigenschaften erforderliche Aufwand ist im Vergleich zu jenem, der notwendig wird, wenn ungeeignete URIs gewählt wurden, gering. Berücksichtigt werden muß auch, daß URIs, wurden sie erst einmal bekannt gemacht, meist vielfach benutzt werden und selbst kleine Zeiteinsparungen bei der Benutzung in Summe eine wesentliche Verbesserung der Benutzbarkeit darstellen.

Leitlinien für den Entwurf von URIs

In den folgenden Beispielen werden URIs der Form https://www.example.org/foo/ anstelle von https://www.example.org/foo gezeigt. Welcher der beiden Formen der Vorzug zu geben ist, ist letztlich Geschmackssache. Üblich ist eine serverseitige Weiterleitung von https://www.example.org/foo auf https://www.example.org/foo/, wenn die Datei foo auf dem Server nicht existiert. Der Schrägstrich am Ende des URIs zeigt an, daß der URI auf das Standarddokument eines Verzeichnisses zeigt.

Auf konkrete Implementierungshinweise wurde verzichtet, wo diese nicht unbedingt zur Erläuterung erforderlich sind.

Aus der Verwendung von URIs durch Mensch und Computer lassen sich folgende Entwurfsziele für URIs herleiten:

Auf Basis dieser Ziele wurde die folgende Liste von Leitlinien entwickelt, die für Entwurf und Analyse von URIs herangezogen werden können. Die einzelnen Leitlinien werden durch Beispiele aus der Praxis und die Betrachtung verschiedener Lösungsalternativen veranschaulicht.

URIs sollten bedeutungstragende Bezeichner sein und müssen nicht Pfadangaben in einem Dateisystem entsprechen.

URIs müssen und sollen vielfach nicht den Pfaden, also Verzeichnis- und Dateinamen, unter denen die Ressourcen auf dem Server physisch abgelegt sind, entsprechen. Gute Webserver bieten die Möglichkeit der freien Konfiguration von URIs, die deren beliebige Zuordnung zu Ressourcen auf dem Server einschließt.

Die Anordnung von Seiten in Ordnern und die Benennung von HTML-Dateien sollen nicht zum Ziel haben, deren Verwaltung durch den Webmaster zu erleichtern, sondern einziges Ziel sollte die Vereinfachung des Auffindens und die konsistente Benutzung durch den Besucher der Website sein. Schließlich wird weit mehr Zeit mit dem Besuchen von Websites verbracht, als mit deren Wartung.

Obwohl es sich bei URIs nicht um Pfadangaben in einem Dateisystem handelt, besitzt der Schrägstrich („/“) die Funktion des Hierarchietrennzeichens. Ähnlich zu Pfadangaben kann über relative URIs aus Ressourcen zu anderen Ressourcen verwiesen werden. Ein Hyperlink mit Zieladresse ../../ auf der Seite https://www.example.org/2006/articles/web/ würde beispielsweise in den URI https://www.example.org/2006/ aufgelöst.

Subdomains sollten logisch strukturieren und müssen nicht notwendigerweise der physischen Organisation der Server entsprechen.

Die Namen von Domains und Subdomains sollten nicht vorwiegend die physische Organisation der Server wiedergeben, sondern die Bedeutung der Server. Domains wie www.example.org und www2.example.org sind daher zu vermeiden. Die Lastverteilung auf mehrere Webserver kann immer noch für den Benutzer transparent auf der Serverseite erfolgen. Bei Einführung von Subdomains gilt zu beachten, daß damit die Möglichkeit des relativen Verweisens auf Ressourcen einer der anderen Subdomains verloren geht.

In URIs für das Web wird, historisch bedingt, HTTP-URIs häufig die Subdomain www dem Domainnamen vorangestellt. Dies ist technisch zwar nicht erforderlich, kann aber helfen, den URI in Angaben ohne Protokoll leichter als solchen erkennbar zu machen. Eine der beiden Varianten, also https://www.example.org/ oder https://example.org/, sollte als kanonische Form festgelegt und von anderen Formen auf diese weitergeleitet werden. Insbesondere im kommerziellen Umfeld ist die Nutzung der Subdomain www ratsam.

Serverseitige technische Details wie eingesetzte Technologien sollten nicht in URIs aufscheinen.

Im Laufe der Zeit können die am Webserver und auf Seiten des Benutzers eingesetzten Technologien gegen andere Technologien ausgetauscht werden. Bestehende URIs, die an bestimmte Technologien gebunden sind, verlieren damit ihre Gültigkeit und Umleitungen müssen eingerichtet werden. Dies kann dazu führen, daß URIs eine unzutreffende Bedeutung erlangen, etwa, wenn https://www.example.org/foo.html eine PDF-Datei zurückgeben würde, weil die Ressource nicht mehr im HTML-Format verfügbar ist.

Dateinamenserweiterungen wie .cgi, .php und .aspx sollten ebenfalls nicht in URIs aufscheinen. Dies gilt auch für serverseitige Skripte und Verzeichnisse, in denen enthaltene Skriptdateien zur Ausführung freigegeben wurden. Auch diese sind ein serverseitiges Detail, das für den Benutzer keine Bedeutung besitzt, sondern im Gegenteil, die Suche nach Sicherheitslücken des Servers erleichtert. Anstelle von https://www.example.org/cgi-bin/search.pl?q=Hello bietet sich ein URI wie https://www.example.org/search/?q=Hello an.

Selbst Anfrageparameter können in einigen Fällen versteckt werden, indem etwa anstelle von https://www.example.org/books/?isbn=3794602048 der URI https://www.example.org/books/3794602048/ benutzt wird. Einerseits wird dadurch der URI kompakter, andererseits wird das serverseitige Implementierungsdetail des Skripts, das die zur ISBN-Nummer gehörige Information zurückgibt, für den Benutzer transparent gemacht.

Der Dateiname von Verzeichnisstandarddokumenten sollte nicht in URIs aufscheinen.

Standarddokumente sind jene Dokumente, die für URIs, welche auf ein Verzeichnis verweisen, zurückgegeben werden. Eine Anfrage mit dem URI https://www.example.org/foo/ würde das Standarddokument des Verzeichnisses foo anfordern. Unter vielen Webservern wird das Standarddokument eines Verzeichnisses als Datei gespeichert. Der Name dieser Datei richtet sich dabei oft nach der serverseitig eingesetzten Technologie, sodaß bei einem Technologiewechsel Dateien umbenannt oder die Konfiguration des Servers angepaßt werden müßten.

Der Name der Dateien, in denen die Standarddokumente gespeichert sind, hat für den Benutzer keine Bedeutung. Anstelle von URIs wie https://www.example.org/articles/default.aspx sollte daher https://www.example.org/articles/ als kanonische Form benutzt werden. Durch Setzen eines passenden Statuscodes können Suchmaschinen angewiesen werden, URIs mit expliziter Angabe des Dateinamens wie https://www.example.org/articles/default.aspx nicht zu indizieren. Sofern URIs mit expliziter Dateiangabe in Umlauf geraten, wäre es notwendig, Weiterleitungen einzurichten, damit bestehende Hyperlinks weiterhin auf die Ressource verweisen.

URIs sollten für den Benutzer relevante Information enthalten, bedeutungslose Identifikationsnummern sollten vermieden werden.

Für den Benutzer bedeutungslose Information wie interne Identifikationsnummern, beispielsweise GUIDs oder Kennzahlen, sollten in URIs vermieden werden. URIs, die Identifikationsnummern enthalten, finden sich häufig bei Websites, deren Inhalte in Datenbanktabellen abgelegt sind. Dies ist bei einigen Inhaltsverwaltungssystemen der Fall. Die Folge davon sind meist unhandliche URIs wie https://www.example.org/index.php?article_id=982361. Geeigneter wäre der URI https://www.example.org/articles/982361/, wobei im Idealfall auch die Artikelkennzahl vermieden werden kann, sofern es sich dabei nicht um eine bekannte und bedeutungsvolle Artikelnummer handelt.

Ausnahmen bilden Identifikationsnummern wie ISBN und Angebotsnummern, die eine Bedeutung für den Benutzer besitzen und damit wichtige Information transportieren. So könnte eine Liste von Büchern unter URIs wie https://www.example.org/books/3794602048/ verfügbar gemacht werden, wobei die Nummer am Ende des URIs der ISBN eines Buches entspricht. Bei Angebot von Produkten auf einer Website bieten sich URIs wie https://www.example.org/shop/products/932457/ für die einzelnen Produktbeschreibungen an.

Die bei einigen Weblogs üblichen dauerhaften URIs wie https://www.example.org/PermaLink.aspx?guid=d57ace50-2762-4b19-b07d-39421829d410 sind ungeeignet, da Details der serverseitigen Implementierung offen gelegt und darüberhinaus die nicht auf die Lesbarkeit durch den Menschen hin optimierten GUIDs benutzt werden. Bei Weblogs geeigneter ist die Anordnung der Artikel nach dem Datum ihrer Erstellung, versehen mit einer laufenden Artikelnummer pro Tag oder einem sprechenden Titel wie https://www.example.org/blog/2006/01/22/1/ oder https://www.example.org/blog/implementing-web-services/.

Ausnahmen stellen beispielsweise Webforen dar, in denen den einzelnen Artikeln aufgrund mangelnder Struktur und hoher Zahl keine sinnvollen sprechenden URIs zugeordnet werden können. Dennoch ist auch hier darauf zu achten, daß die benutzten Identifikationsnummern minimal sind und nicht wie GUIDs immer eine feste Länge einnehmen, sondern etwa laufende Artikelnummern mit zufälligem Anteil darstellen. Auch die Sortierung nach dem Datum, wie sie zuvor am Beispiel von Weblogs beschrieben wurde, kann sinnvoll sein. Im URI https://www.example.org/forum/2006/05/t130140/ wird die laufende Threadnummer mit dem Erstellungsdatum in Zusammenhang gebracht.

Der Inhaltstyp von Ressourcen sollte nicht in deren URIs aufscheinen, wenn dies nicht unbedingt erforderlich ist.

Wenngleich zur Zeit Webseiten häufig im HTML-Format vorliegen, kann in Zukunft eine andere Technologie zur deren Codierung eingesetzt werden. Die Umstellung von HTML auf XHTML könnte bereits die Änderung der Dateinamenserweiterungen von .html in .xhtml erfordern. In Folge wäre es notwendig, eine dauerhafte Weiterleitung von https://www.example.org/joe/cv.html auf https://www.example.org/joe/cv.xhtml einzurichten.

Daher empfiehlt sich, den Inhaltstyp einer Ressource oder einer Gruppe von Ressourcen semantisch gleichbedeutenden Inhalts im URI nicht anzugeben. Ein URI wie https://www.example.org/joe/cv/ wäre nicht an einen bestimmten Inhaltstyp der Ressource gebunden und könnte den Inhalt mittels Content Negation in passender Form codiert zurückgeben. Daneben können URIs zu den verschiedenen zur Auswahl stehenden Inhaltstypen einer Ressource definiert werden, um deren spezifische Ansteuerung zu ermöglichen.

In URIs sollte zwischen Ländern und Sprachen unterschieden werden.

Bei der Gestaltung von URIs muß zwischen Ländern und Sprachen unterschieden werden. Ein Unternehmen kann in mehreren Ländern tätig sein. In einem Land können ein oder mehrere Sprachen und eine Sprache kann zugleich in mehreren Ländern gesprochen werden. So könnte ein Anbieter unterschiedliche Inhalte in Deutschland und Österreich anbieten, obwohl in beiden Ländern Deutsch gesprochen wird. Die Website eines Unternehmens in Polen könnte Inhalte sowohl in Polnisch als auch in Deutsch zur Verfügung stellen.

Top-Level-Domains wie .de, .at und .pl sind Staaten zugeordnet. Sie bezeichnen nicht bestimmte Sprachen, auch wenn die meisten Websites mit .de-Domain in Deutsch verfaßt sind. Ist ein Anbieter sowohl in Deutschland als auch in Österreich aktiv, könnte er die Domains example.de und example.at nutzen. Die beiden Websites sind in Deutsch gehalten, weisen aber länderspezifische Inhalte auf. Als Alternative zu mehreren Top-Level-Domains könnten für die Länder Subdomains wie de.example.org und at.example.org einer länderunabhängigen Domain eingesetzt werden.

Werden Ressourcen in mehreren Sprachen unter einer Domain angeboten, bestehen mehrere Möglichkeiten: Über Content Negotiation könnte bei Adressierung einer Ressource über einen URI wie https://www.example.org/angebote/ die Ressource in einer plausiblen Sprache zurückgegeben werden. Zudem könnte dem Benutzer die Möglichkeit der Sprachauswahl geboten werden, wobei die gewählte Sprache clientseitig in einem Cookie oder bei erforderlicher Anmeldung serverseitig in einem Profil gespeichert wird.

Alternativ oder zusätzlich kann eine bestimmte Sprachversion einer Ressource über einen eigenen URI bezeichnet werden. Üblich sind URIs wie https://www.example.org/de/artikel/, https://www.example.org/artikel.de, https://de.example.org/artikel/ und https://www.example.org/articles/?lang=de. Werden die Teile des URI hinter dem Domainnamen lokalisiert, sind die Namen zwar für Benutzer einer bestimmten Sprache leichter verständlich, der Wechsel zwischen verschiedenen Sprachversionen einer Ressource durch einfaches Austauschen des Sprachkürzels im URI wird jedoch erschwert.

Die Liste der Anfrageparameter in URIs sollte minimal sein.

Bei Verwendung von Anfragezeichenfolgen sollten serverseitig erstellte URIs immer eine minimale Anzahl an Parametern enthalten, um die Lesbarkeit zu verbessern und das Setzen von Hyperlinks auf die Seite zu vereinfachen. Insbesondere Sitzungskennzahlen und nicht gesetzte Optionen sollten in URIs nicht aufgeführt werden. Werden für in der Anfragezeichenfolge nicht aufgeführte Parameter Standardwerte definiert, können die Parameter weggelassen werden, wenn der Standardwert übergeben werden soll.

Zusätzlich sollte darauf geachtet werden, daß bei kanonischen URIs die Reihenfolge und Codierung der Parameter eindeutig festgelegt ist. Durch diese Maßnahme wird die Verarbeitung mehrerer URIs einer Domain durch den Menschen erleichtert. Werden ungültige Parameter oder Parameterwerte angegeben, sollte durch Setzen des passenden Statuscodes angezeigt werden, daß die Ressource nicht existiert. Damit kann die Indizierung des URIs durch Suchmaschinen verhindert werden.

Das schrittweise Verkürzen der URIs durch den Benutzer sollte unterstützt werden.

Die aus dem URI https://www.example.org/web/articles/xhtml/ durch Verkürzen abgeleiteten URIs https://www.example.org/, https://www.example.org/web/, https://www.example.org/web/articles/ und https://www.example.org/web/articles/xhtml/ sollten zu Dokumenten führen. Von diesen Seiten aus kann auf die direkten Unterdokumente der jeweiligen Seite verwiesen werden. So könnte unter https://example.org/web/articles/ eine Übersicht der zum Thema Web verfügbaren Artikel bereitgestellt werden. Die URIs geben die Struktur der Website konsistent wieder.

Zugriffe über nicht-kanonische URIs sollten zum kanonischen URI weitergeleitet werden, um die Verbreitung nicht-kanonischer URIs zu verringern.

Jede Ressource besitzt zu jedem Zeitpunkt genau einen kanonischen URI. Ist die Ressource auch unter anderen URIs erreichbar, etwa aus Gründen der Kompatibilität zu bestehenden Hyperlinks oder um auf häufige Fehleingaben benutzerfreundlich reagieren zu können, so sollte eine dauerhafte Weiterleitung auf den kanonischen URI erfolgen, um zu vermeiden, daß die nicht-kanonischen URIs der Ressource weiter verbreitet werden.

Theoretisch ist es zwar nicht erforderlich, eine Ressource überhaupt unter mehr als einem URI bereitzustellen, in der Praxis existieren jedoch Fälle, in denen diese Vorgehensweise sinnvoll ist: Aus Gründen der Benutzbarkeit sollte es irrelevant sein, ob der Benutzer eine Seite über einen URI ansteuert, in dem Groß- und Kleinschreibung nicht mit der Schreibung des kanonischen URIs übereinstimmen. Weiterhin sollte es nicht relevant sein, ob der Benutzer abschließende Schrägstriche anführt oder wegläßt.

Fehleingaben in URIs bei Anfragen sollten tolerant verarbeitet werden.

Durch Analyse von Zugriffsprotokollen können häufige Fehleingaben von Verzeichnis- und Dokumentnamen in URIs ermittelt und dauerhafte serverseitige Weiterleitungen eingerichtet werden. Kann aufgrund der Zieladresse der Anfrage nicht eindeutig entschieden werden, welchen URI der Benutzer eingeben wollte, bietet sich an, in die zurückgegebene Seite die möglichen URIs in Form von Hyperlinks aufzuführen und dem Benutzer die Auswahl zu überlassen. Durch Zurückgebe eines passenden Statuscodes kann verhindert werden, daß Suchmaschinen den falsch geschriebenen URI indizieren.

Besteht die Gefahr, daß Benutzer Domainnamen falsch schreiben, empfiehlt sich, Anfragen, die über diese Domainnamen eintreffen, auf die kanonische Domain weiterzuleiten. So könnte von https://www.exmple.org/articles/ eine Weiterleitung auf https://www.example.org/articles/ eingerichtet werden. Dies betrifft auch die Verwendung von Subdomains. https://example.org/articles/ könnte auf das kanonische https://www.example.org/articles/ weitergeleitet werden oder umgekehrt. Auch die Weiterleitung von https://www.example.org/foo auf das kanonische https://www.example.org/foo/ oder umgekehrt ist sinnvoll.

URIs sollten das Wachstum der Website unverändert überdauern.

Bereits beim Entwurf von URIs sollte das mögliche Wachstum der Website berücksichtigt werden. Insbesondere eine Trennung zwischen aktuellen Ressourcen und Archiv, bei der nicht mehr aktuelle Inhalte in das Archiv verschoben werden, kann problematisch sein. Ist etwa die aktuelle Ausgabe einer Zeitschrift unter dem URI https://www.example.org/issues/current/ abrufbar, würde sich die durch den URI bezeichnete Ressource bei erscheinen jeder neuen Ausgabe ändern. Bestehende Hyperlinks mit dieser Zieladresse könnten zwar weiterhin aufgelöst werden, würden aber nicht auf jene Ressource verweisen, auf die ursprünglich verwiesen wurde.

Eine mögliche Lösung stellt das Einrichten einer dauerhaften Weiterleitung von https://www.example.org/issues/current/ auf den kanonischen URI der jeweils gerade aktuellen Ausgabe dar. So würde im März 2006 auf https://www.example.org/issues/2006/03/ weitergeleitet. Benutzer können dann über den URI https://www.example.org/issues/current/ auf die aktuelle Ausgabe zugreifen, ohne Datum und Nummer der Ausgabe kennen zu müssen. Zudem wird die Möglichkeit des direkten Verweisens auf eine bestimmte Ausgabe geboten.

Geeigneter als die Anordnung der Inhalte nach thematischen Kategorien direkt nach dem Domainnamen ist die Anordnung der Inhalte anhand ihres Veröffentlichungsjahres, etwa https://www.example.org/2006/articles/web/xhtml/ anstelle von https://www.example.org/articles/web/xhtml/. Die Angabe des Jahres direkt nach dem Domainnamen und noch vor dem Kategoriennamen hat den Vorteil, daß die Bedeutung der Kategorie aus der enthaltenen Jahreszahl erschlossen werden kann und Kategorien im Laufe der Jahre verschwinden können.

Genutzte Domains sollten nicht abgegeben werden.

Während mittels Weiterleitungen alle Szenarien des Umzugs von Ressourcen innerhalb einer oder mehrerer kontrollierter Domains gelöst werden können, kann der Verlust der Kontrolle über einen Domainnamen dazu führen, daß URIs dauerhaft ungültig werden, weil keine Weiterleitungen eingerichtet werden können. Eine mögliche Lösung dieses Problems stellen PURLs dar. In der Praxis sollte es jedoch ausreichen, sicherzustellen, daß Domains nicht irrtümlich in fremde Hände gelangen.

Bei Fusion mehrerer Unternehmen oder Aufkauf eines anderen Unternehmens sollten die Domainnamen der ursprünglichen Unternehmen nicht aufgegeben werden. Stattdessen können Weiterleitungen von den alten Domains zu der neuen Domain eingerichtet werden. Soweit sinnvoll sollten auch die URIs zu einzelnen Ressourcen einer bestimmten Domain des alten Unternehmens weiterhin auf diese Ressourcen verweisen, selbst wenn sie mit neuen kanonischen URIs versehen und physisch auf dem neuen Server abgelegt wurden.

URIs sollten sich für die Verwendung und Übertragung abseits des Computers eignen.

URIs werden in zunehmendem Maße in Medien abseits des Computers wiedergegeben, etwa auf Werbeplakaten, als Beschriftung auf Fahrzeugen und Schaufenstern, auf Visitenkarten, in Zeitungen, Zeitschriften und Büchern sowie in Radio und Fernsehen. Im direkten Gespräch oder am Telefon werden URIs in gesprochener Form übermittelt. Daher ist ratsam, bei der Gestaltung von URIs diese Arten der Verwendung zu berücksichtigen. URIs sollten in den Zielsprachen des Angebots leicht auszusprechen und einzugeben sein. Durch Verzicht auf Groß- und Kleinschreibung kann die Komplexität der URIs verringert werden.

Anstelle des URIs https://www.example.org/ findet man häufig die verkürzte Form www.example.org, bei der Protokoll und abschließender Schrägstrich der besseren Lesbarkeit wegen weggelassen werden. Die Angabe der Subdomain www bei in mehreren Medien eingesetzten URIs ist ratsam, da www.example.org eher als URI erkannt wird als example.org. Ressourcen mit langem kanonischem URI können kurze URIs zugewiesen werden, die zum kanonischen URI weiterleiten.

Falls der Domainname www.example.org die kanonische Form darstellt, sollte eine dauerhafte Weiterleitung von https://example.org/ auf https://www.example.org/ eingerichtet werden. Andernfalls kann es vorkommen, daß Benutzer den Domainnamen ohne www. eingeben und die Anfrage nicht aufgelöst werden kann, da die Subdomain www nicht existiert. Wird die Form ohne www. als kanonischer Domainname benutzt, ist eine Weiterleitung auf die Form mit www. ebenfalls ratsam.

Schlußwort

Die wichtigste Regel beim Entwurf von URIs ist, sich die Website einzig und alleine aus Sicht der Benutzer zu vergegenwärtigen und auf Basis dieser Sicht die Struktur des Angebots unter Berücksichtigung der zuvor genannten Punkte zu entwerfen. Werden URIs zur Steigerung der Benutzbarkeit einer bestehenden Website neu entworfen, sollten dauerhafte Weiterleitungen von den bestehenden URIs hin zu den neuen, kanonischen URIs eingerichtet werden, damit bereits in Hyperlinks, Lesezeichen und Veröffentlichungen genannte URIs weiterhin aufgelöst werden können.

Bei der Auswahl der auf dem Server eingesetzten Technologien und des Webhostingangebots empfiehlt sich, auf die gebotenen Konfigurationsmöglichkeiten zu achten. Die Websites vieler Internetdienstanbieter, die Webhosting anbieten, führen zwar plakativ die auf dem Server installierten Technologien auf, verschweigen aber, welche Einstellungen durch den Kunden am Webserver vorgenommen werden können.