Wie funktioniert das?
Der Server entscheidet.
Wie weiß der Server (oder etwas anderes? Ich bin ziemlich Neuling), welche URL bedeutet, wenn er eine Anfrage erhält?
Der Server hängt von seiner Konfiguration ab. Bei Unix-basierten Servern wird dies häufig von einer oder mehreren Textdateien gehandhabt, die häufig als "Konfigurationsdateien" bezeichnet werden. Bei der Einrichtung des Servers können Sie dies angeben. Details dazu, wie Sie dies festlegen, hängen von der verwendeten Webserver-Software ab.
(Es gibt in der Regel eine Vielzahl von Tutorials für beliebte Webserver und CGI-Pakete. Wenn also ein Websiteadministrator nicht weiß, wie er vorgeht, liest er normalerweise Beispiele / Dokumentation / Tutorials. Wenn Sie also nach einer Dokumentation über Wenn Sie Webserver wie Apache verwenden, finden Sie wahrscheinlich Informationen zum Einrichten von Drupal. Wenn Sie jedoch Informationen zu Drupal suchen, finden Sie wahrscheinlich einen Abschnitt mit Informationen zur Konfiguration von Apache Verwenden Sie Drupal. Bei so viel verfügbarer Dokumentation müssen Website-Administratoren normalerweise nicht zu sehr kämpfen, um relevante Details für die Softwarepakete zu finden, die sie verwenden möchten.)
Der HTTP 1.1-Client teilt die URL in drei Teile auf:
- Das Protokoll (zB http / https)
- Die Site (zB example.com)
- die Ressource (zB /somedir/file.htm)
Das kann eine leichte Vereinfachung sein. Einige ältere URLs ließen z. B. ftp: // Benutzername @ Kennwort: example.com/somedir/file zu, obwohl neuere Webbrowser diese Unterstützung neigten, z. B. MS KB 8344389, aus Sicherheitsgründen (einschließlich eines erheblichen Missbrauchs) aufgetreten ist, z. B. http://paypal.com/gibberish%40PhishingSite.example.com/gibberish würde% 40 in ASCII 64 konvertieren. Dies ist das @, wodurch der Benutzername von paypal.com/gibberish für die Anmeldung bei PhishingSite verwendet wird .example.com, das einfach den Login akzeptiert und die Benutzer nach ihrem PayPal-Passwort fragt. Die Benutzer sehen paypal.com am Anfang der URL und vertrauen ihr.
Sicher, es gibt einige "Standards" wie # in einer URL, die der Web-Client erkennt und diese nicht an den Server sendet. Stattdessen behandelt der Web-Client den Text nach dem # als Ankertext, zu dem gesprungen werden soll. % Wird auch für die Umgehung von Hex-Zeichen verwendet. Web-Clients neigen dazu, das zu verstehen.
Andere Details können bis zu dem Server sein. Zum Beispiel haben viele Webserver? Starten einer Liste von Parametern und Verwenden des & (oder vieler Semikolons?) zum Aufteilen von Parametern innerhalb der Liste der Parameter. Dies ist jedoch nur ein allgemeines Verhalten vieler Webserver. Es gibt kein Teil von HTTP, das Webserver dazu zwingt, dies zu würdigen. Eigentlich kann der Webserver damit umgehen, was der Webserver will, und der Webclient benötigt dafür wahrscheinlich keine besondere Unterstützung.
Wenn Sie jemals einen HTTP-Server einrichten, werden Sie wahrscheinlich verstehen, dass ein Teil dieser Konfiguration angibt, was mit den angeforderten Ressourcen zu tun ist. Sie können beispielsweise sagen, dass alles, das an / gesendet wird, Dateien aus dem lokalen / srv / httpdocs / -Bereich der Festplatte lädt, mit Ausnahme von / cgi-bin /, das ein Programm in / cgi-bin / und alles unter / scripts ausführen wird / und die Endung mit .pl werden vom PERL-Interpreter ausgeführt.
Die spezifischen Details variieren je nach Konfiguration des Webservers. Daher gibt es keinen universellen Standard, der dem Webclient mitteilt, ob garantiert wird, dass eine Kopie einer statischen Seite oder die Ausgabe eines Programms erhalten wird, das ausgeführt wird. Der Web-Client kann nur erwarten, dass der Web-Server darauf reagiert, wenn der Web-Client eine Ressource anfordert.