Routing per '/' ohne Raute-Zeichen ("Anchor") und rein clientseitig - wie geht das?

Hallo zusammen

Ich frage mich immer wieder, wie clientseitiges Routing (z.b. bei Angular) über meinserver.com/xyz geht, auch wenn ich auf dem Server

a.) Weder ein Pfad namens “xyz”

noch

b.) eine entsprechende Regel z.B. per .htaccess/mod_rewrite besteht?

Wie ich bisher gemeint habe (falsch?) geht doch zuerst immer alles an der Server, was hinter dem Domainname nach einem ‘/’ aufgerufen wird??

Ich könnte es ja noch nachvollziehen wenn ein “Separator” (z.B. ‘#’, der “Anchor”, welcher das clientseitig über ein <a …>-Tag regelt) verwendet werden würde.

Oder hat die Weiterleitungsregel in JavaScript mit meinserver.com/xyz einfach ne höhere Priorität, geht also zuerst Clientseitig rein und wird dann dort verarbeitet so dass es gar nie soweit kommt dass ein GET-Request auf dem Server abgesetzt wird…?

Jedenfalls widerspricht das allem, was ich bisher zu wissen geglaubt habe…

Vielen Dank für die Feedbacks!

Also auf Anhieb würden mir da nur JavaServer Pages und JavaServer Faces einfallen, denn da kann man das rewrite auch programmtechisch gestalten. Rewrite-Rules tauchen dann auch nicht in htaccess auf, sondern in (afair) mehreren Konfigurationsdateien (xml).

Danke für die Antwort. ABER: Die Angular-Beispiel-Anwendung von mir, wo ich dieses Verhalten feststellte, hat aktuell definitiv NULL Logik oder Regeln auf dem Server, ob man nun Apache, NodeJS, nginx, einen Servlet-Container, IIS oder was auch immer verwendet spielt in diesem Fall keine Rolle… (diese ist ja vom Server “entkoppelt” und kommuniziert wenn schon über json)

Habe noch im (na ja, hier evtl. nicht so beliebten und alten ;-)) java-forum gepostet, die Antwort dort scheint einigermassen aufschlussreich zu sein:

(-> Service Worker, welcher als Proxy fungiert)

Manchmal wird es auch nicht gerne gesehen, wenn die gleiche Sache in anderen Foren gepostet wird. Dann muss ich mich entschuldigen - allerdings hole ich mir gerne unterschiedliche Meinungen ein, und meist geht’s dann auch ein wenig schneller! :wink:

Hat sich erledigt, die Ursache war eine serverseitige Regel, welche der NodeJS-Dev-Server sich “einfach so” erlaubt einzusetzen…:frowning:

(Mea culpa - aber wie schräg ist denn sowas??)