Ich bin ein wenig verwirrt, wie URLs funktionieren. Früher, als ich HTML und so lernte, wusste ich, dass nach dem Domänennamen der Speicherort einer Datei kommt, die wir laden möchten (z. B. website.com/einOrdner/eineDatei.html). Und es war einfach, ich konnte es verstehen.
Vor kurzem musste ich noch mehr über das Web lernen und habe festgestellt, dass URLs komplizierter sind. Zum Beispiel:
- Drupal-Links sind wie somewebsite.com/node/43
- REST-Anfragen sind wie somewebsite.com/books/32
- nach '?' können Sie einige Parameter übergeben
Wie funktioniert das? Woher weiß der Server (oder etwas anderes? Ich bin ziemlicher Neuling), was die URL bedeutet, wenn er eine Anfrage erhält? Es könnte sein:
- Standort der Ressource
- Drupal-Ansicht
- REST-Anforderung
- einige andere Dinge?
Ich weiß nicht, ob meine Frage Sinn ergibt. Ich hoffe, Sie verstehen, was mich verwirrt.
Antwort1
Wie soll das gehen?
Der Server entscheidet.
Woher weiß der Server (oder etwas anderes? Ich bin ein ziemlicher Neuling), was die URL bedeutet, wenn er eine Anfrage erhält?
Der Server ist auf seine Konfiguration angewiesen. Bei Unix-basierten Servern wird dies häufig durch eine oder mehrere Textdateien erledigt, die oft als „Konfigurationsdateien“ bezeichnet werden. Beim Einrichten des Servers können Sie dies angeben. Einzelheiten dazu variieren je nach der von Ihnen verwendeten Webserver-Software.
(Es gibt in der Regel viele Tutorials für beliebte Webserver und CGI-Pakete. Wenn ein Website-Administrator also nicht weiß, wie das geht, beginnt er normalerweise damit, Beispiele/Dokumentationen/Tutorials zu lesen. Wenn Sie also nach Dokumentation zu einem Webserver wie Apache suchen, werden Sie wahrscheinlich auch Informationen zum Einrichten von Drupal finden. Wenn Sie andererseits Informationen zu etwas wie Drupal suchen, werden Sie wahrscheinlich einen Abschnitt der Dokumentation finden, in dem beschrieben wird, wie Apache für die Verwendung von Drupal konfiguriert wird. Bei so viel verfügbarer Dokumentation müssen sich Website-Administratoren normalerweise nicht allzu sehr abmühen, um relevante Details zu den Softwarepaketen zu finden, die sie verwenden möchten.)
Der HTTP 1.1-Client neigt dazu, die URL in drei Teile aufzuteilen:
- Das Protokoll (zB http/https)
- Die Site (z. B. example.com)
- die Ressource (zB /somedir/file.htm)
Das ist vielleicht eine leichte Vereinfachung. Einige ältere URLs erlaubten etwas wieftp://Benutzername@Passwort:example.com/somedir/fileAllerdings neigen neuere Webbrowser dazu, diese Unterstützung zu entfernen, z. B.MS KB 8344389, aus Sicherheitsgründen (einschließlich einer beträchtlichen Anzahl von Missbrauchsfällen, die aufgetreten sind, z. B.http://paypal.com/gibberish%40PhishingSite.example.com/gibberishwürde %40 in ASCII 64 umwandeln, also das @, wodurch der Benutzername paypal.com/gibberish zum Anmelden bei PhishingSite.example.com verwendet wird, das die Anmeldung einfach akzeptiert und die Benutzer nach ihrem PayPal-Passwort fragt. Die Benutzer würden paypal.com am Anfang der URL sehen und dieser vertrauen.
Sicher, es gibt einige „Standards“, wie z. B. # in einer URL, die der Webclient erkennt und nicht an den Server sendet. Stattdessen behandelt der Webclient den Text nach dem # als Ankertext, zu dem gesprungen werden kann. Außerdem wird % zum Escapen von Hexadezimalzeichen verwendet. Webclients verstehen das in der Regel.
Andere Details können vom Server abhängen. Viele Webserver beginnen beispielsweise eine Parameterliste mit einem ? und verwenden das & (oder viele Semikolons?), um Parameter innerhalb der Parameterliste aufzuteilen. Dies ist jedoch einfach ein gängiges Verhalten vieler Webserver. Es gibt keinen Teil von HTTP, der Webserver dazu zwingt, dies zu berücksichtigen. Tatsächlich kann der Webserver damit umgehen, wie er möchte, und der Webclient benötigt dafür wahrscheinlich keine spezielle Unterstützung.
Wenn Sie schon einmal einen HTTP-Server eingerichtet haben, werden Sie wahrscheinlich verstehen, dass ein Teil dieser Konfiguration darin besteht, anzugeben, was mit den angeforderten Ressourcen geschehen soll. Sie könnten beispielsweise sagen, dass alles, was an / gesendet wird, Dateien aus dem Bereich /srv/httpdocs/ der lokalen Festplatte lädt, mit Ausnahme von /cgi-bin/, das ein in /cgi-bin/ befindliches Programm ausführt, und dass alles unter /scripts/ und mit .pl endend vom PERL-Interpreter ausgeführt wird.
Die genauen Details variieren je nach Konfiguration des Webservers. Es gibt also keinen universellen Standard, der dem Webclient sagt, ob er garantiert eine Kopie einer statischen Seite oder die Ausgabe eines ausgeführten Programms erhält. Der Webclient kann lediglich erwarten, dass der Webserver antwortet, wenn er eine Ressource anfordert.
Antwort2
Der Webserverwissenjede dieser Bedeutungen – in allen Fällen empfängt es einfach den Ressourcenpfad, führt ihn durch das Hauptprogramm der Website und sendet Ihnen die resultierende Ausgabe. Und natürlich machen verschiedene Programme verschiedene Dinge mit dem Pfad, den sie erhalten haben.
Wenn kein Programm konfiguriert ist, sucht es nach einer Datei mit diesem Namen und stellt sie direkt bereit. (PHP und CGI liegen oft irgendwo dazwischen: Der Webserver sucht immer noch nach einer Datei, führt diese dann aber aus.)selbstals Programm.)
Das Einzige, /node/43was es zu einer „Drupal-Ansicht“ macht, ist, dass der Webserver so konfiguriert wurde, dass er /node/<anything>an die Drupal-Software weiterleitet. Die Webseite wird immer noch als Ressource betrachtet, auch wenn sie dynamisch generiert wurde.
(Drupal selbst weiß natürlich, dass, wenn der Pfad mit beginnt, /node/die Ansichts-ID folgt.)
REST-Anfragen sind ebenfalls ganz normale Ressourcenanfragen. Was sie „RESTful“ macht, ist lediglich der allgemeine Stil und das Verhalten. (URLs im Stil von beispielsweise /book/345passen zur REST-Ideologie, während /api/get_book?id=345dies nicht der Fall ist.)