K-F: Frage zum Apache

Hallo,
nachdem ich in dem zuständigen Forum leider viele Tips erhalten hatte, die das Problem nicht lösten, hoffe ich, dass hier in dem Forum jemand ist, der auf dem Rechner ein lokales XAMPP erstellt und dann in Apache Domains erfolgreich definiert hat.

Ich habe XAMPP/Apache erfolgreich installiert. Hat jemand von Euch eine Anleitung, wie ich meine Domains im aktuellen Apache definieren muss, damit ich sie lokal testen kann?

  1. Hi there,

    Ich habe XAMPP/Apache erfolgreich installiert. Hat jemand von Euch eine Anleitung, wie ich meine Domains im aktuellen Apache definieren muss, damit ich sie lokal testen kann?

    Was meinst Du mit "Domains"?

  2. Hallo K-F,

    unter "Domain" verstehe ich sowas wie www.example.com.

    Bitte beschreibe

    • was genau du tun willst, deine Frage lässt viele mögliche Varianten offen. Du kannst statt deiner echten Domainnamen gerne sowas wie fk.example.com verwenden.
    • welches Betriebssystem du verwendest
    • was Du bisher probiert hast und welche Schwierigkeiten Du damit hattest.

    Sonst schreiben wir hier Romane und dennoch an deinem Bedarf vorbei.

    Grundsätzlich besteht die Lösung in einem passenden Eintrag in der hosts-Datei und namensbasierenden virtuellen Hosts im Apache. Die sind hier dokumentiert, nicht in irgendwelchen Foren.

    Rolf

    --
    sumpsi - posui - obstruxi
    1. unter "Domain" verstehe ich sowas wie www.example.com.

      ja, richtig. Ich möchte z.B. mein fk.example.com lokal testen, bevor ich damit ins Internet gehe.

      • welches Betriebssystem du verwendest

      Windows 11

      Grundsätzlich besteht die Lösung in einem passenden Eintrag in der hosts-Datei und namensbasierenden virtuellen Hosts im Apache. Die sind hier dokumentiert, nicht in irgendwelchen Foren.

      Damit habe ich begonnen, aber nachdem man sich von einem Dokument zum andern ellenlangen Dokument hangeln muss, habe ich es aufgegeben und im XAMPP-Forum nach einer einfachen Anleitung gefragt. Dass man wohl wenig ändern muss, weiß ich von einer Installation, die ich vor mind. 10 Jahren verfolgt habe. Im Forum sind mir dann 10 Links zu Beschreibungen vorgeschlagen worden. Auf diesen thread kam dann sehr schnell die Antwort: "Da sind aber auch einige Beispiele dabei mit veralteter Syntax bzw. gar keiner Access Direktive. Genau genommen kann ich keines dieser Beispiele hier wirklich empfehlen"

      1. Hallo K-F,

        Hast Du einen hosts-Eintrag gemacht?

        Hast Du eine VirtualHost Konfiguration im Apache vorgenommen, wie im verlinkten Apache-Artikel beschrieben, der wirklich nicht so riesig ist? Das geht natürlich nur in der httpd.conf und nicht in einer .htaccess Datei.

        Diese beiden Sachen sollten ausreichen. Exakt vorkauen kann ich Dir den Apache-Teil nicht, weil ich kein Apache-Indianer bin sondern Microsoft IIS verwende. D.h. ich müsste jetzt für dich die 2 Stunden investieren, einen Apache installieren und den Kram durchprobieren. Äh. Nö. Vielleicht weiß unser Raketenwilli, ob es da noch Fallstricke gibt.

        Im IIS klickt man das mit 5-10 Mausklicks im IIS Verwaltungstool zusammen und ist fertig. Aber das, was da bei Apache steht, sieht ziemlich straightforward aus. Die ganzen "Siehe auch" Verweise sind vermutlich nicht so wichtig. Ggf. muss man den Apache neu starten, wenn man die httpd.conf geändert hat.

        Natürlich musst Du die Grundzüge der Apache-Konfiguration kennen. Da kommst Du nicht drum herum, wenn Du einen Webserver verwendest.

        Wenn es nicht geht, wäre es vielleicht hilfreich, wenn Du uns deine hosts-Datei vorzeigst (ohne Kommentare und ohne themenfremde Zeilen) sowie den relevanten Ausschnitt aus deiner httpd.conf. Du könntest bei Problemen auch die error.log Datei des Apache konsultieren. Siehe ErrorLog Direktive im Apache Handbuch.

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Vielleicht weiß unser Raketenwilli, ob es da noch Fallstricke gibt.

          Hm. Ich kann sie nur nicht aufzählen - weil aus den Knoten, die man macht um die Fallstricke nicht zu lang hängen zu lassen, komischerweise fast immer neue Fallstricke raushängen. Aber eine Minimalkonfiguration kann ich erst mal zeigen.

          @K-F

          Also fangen wir mal an...

          (1)

          Zunächst braucht man für einen EINFACHEN virtuellen Host ein Verzeichnis für dessen Dateien.

          Bei mir ist das /var/www/home.example.org/site - Wie man das unter Windows angibt will und brauche ich nicht wissen. Das Verzeichnis muss von dem Benutzer, unter dem der Apache läuft (Blick in die Dok von XAMPP, alternativ in die Diensteverwaltung), mindestens lesbar sein. Sollen Skripte darin schreiben (Dateien anlegen e.t.c.) dann auch beschreibbar.

          (2)

          Sorge (als Admin darfst Du das) durch einen Eintrag in die hosts-Datei (nach meiner Erinnerung ist das)

          C:\Windows\system32\drivers\etc\hosts

          oder durch Manipulation eines DNS-Servers (Was weiß ich denn was was vorhanden ist?) dafür, dass der Hostname (Nicht: „Domain“) home.example.org zu der IP 127.0.0.1 aufgelöst wird. Das geht auch anders, aber 127.0.0.1 reicht Dir wohl erst einmal.

          127.0.0.1 home.example.org
          

          (3)

          Soweit ich das noch weiß, baut dieses XAMPP eine einzige, „monolitische“ http.conf. („Was für ein notlos bewirkter Horror!“)

          An dieses Monster füge man wie folgt an:

          <VirtualHost *:80>
          	ServerAdmin root@localhost
          	ServerName home.example.org
          	DocumentRoot /var/www/home.example.org/site
          	<Directory /var/www/home.example.org/site/>
          		<RequireAll>
          			Require ip 127.0.0.1
          		</RequireAll>
          		Options All +ExecCGI
          		AddHandler cgi-script .cgi .pl .py
          		AllowOverride All
          		AddDefaultCharset UTF-8
          	</Directory>
          </VirtualHost>
          

          Was die Einträge bewirken steht in der schon verlinkten Dok. Wenn man mehr als diese teils von mir ausgewählten Mindestangaben oder anderes will, muss man die Dok (und seinereinenwelchen höchselbst) auch bemühen.

          Ach so: Ich habe den Zugriff nicht grundlos auf den localhost beschränkt. Ich kenne Dein Netz nicht und habe keinerlei Wissen über Dein Wissen. Und da ist das besser so....

          1. Hallo,

            Soweit ich das noch weiß, baut dieses XAMPP eine einzige, „monolitische“ http.conf.

            also so, wie es auch der Standalone-Apache bis Version 2.0 verwendet hat.

            („Was für ein notlos bewirkter Horror!“)

            Im Gegenteil: Alle Einstellungen in einer Datei beieinander zu haben finde ich erheblich komfortabler und übersichtlicher, als die Konfiguration über Dutzende von Einzeldateien zu zersplittern und die dann zu includieren.

            Aber das ist nur meine Meinung.

            Einen schönen Tag noch
             Martin

            --
            Möchtegern-Dichter zum Verleger: "Sie meinen also, ich sollte etwas mehr Feuer in meine Verse legen?" - "Umgekehrt, mein Lieber, umgekehrt. Mehr Verse ins Feuer."
            1. Alle Einstellungen in einer Datei beieinander zu haben finde ich erheblich komfortabler und übersichtlicher, als die Konfiguration über Dutzende von Einzeldateien zu zersplittern und die dann zu includieren.

              Ich brauche nur eine virtuelle Maschine mit Debian und etwas wie eine Teams- oder Zoom-Sitzung um Dich zu überzeugen. Vielleicht reicht ja das hier:

              https://www.digitalocean.com/community/tutorials/how-to-install-the-apache-web-server-on-debian-11

              1. Hi,

                Alle Einstellungen in einer Datei beieinander zu haben finde ich erheblich komfortabler und übersichtlicher, als die Konfiguration über Dutzende von Einzeldateien zu zersplittern und die dann zu includieren.

                Ich brauche nur eine virtuelle Maschine mit Debian und etwas wie eine Teams- oder Zoom-Sitzung um Dich zu überzeugen.

                das glaube ich nicht. Denn ich habe ja beide Varianten kennengelernt - die monolithische Konfiguration eines Apache 2.0, und später die modulare bei einem Apache 2.4. Das Jonglieren mit partiellen Config-Dateien finde ich umständlich, zumal ja bestimmte Details voneinander abhängig sein können. Und die Scripte wie a2enmod, a2ensite usw. verschleiern mir zu sehr, was da wirklich passiert. Ich möchte so etwas explizit sehen oder editieren.

                Und dann kommentiere ich lieber einzelne Direktiven oder auch ganze Abschnitte in der zentralen Config-Datei aus, behalte sie dabei aber im Blick, als Teile in einem anderen Verzeichnis zu parken, wo sie dann aus dem Blick sind und in Vergessenheit geraten.

                Einen schönen Tag noch
                 Martin

                --
                Möchtegern-Dichter zum Verleger: "Sie meinen also, ich sollte etwas mehr Feuer in meine Verse legen?" - "Umgekehrt, mein Lieber, umgekehrt. Mehr Verse ins Feuer."
                1. Und die Scripte wie a2enmod, a2ensite usw. verschleiern mir zu sehr, was da wirklich passiert.

                  Naja. Das (a2enmod, a2enconf, a2ensite) sind zwar große Perl-Skripte, aber im Kern (wenn man all die für gute Fehlermeldungen gemachten Untersuchungen weglässt) legen die doch nur die erforderlichen symbolischen Links von /etc/apache2/[mods|conf|sites]-available/ nach /etc/apache2/[mods|conf|sites]-enabled/ und zeigen dann an, ob man den Apache nur neu laden oder neu starten muss, damit das wirksam wird.

                  Die Skripte (a2dismod, a2disconf, a2dissite) entfernen diese Links und zeigen dann an, ob man den Apache nur neu laden oder neu starten muss, damit das wirksam wird.

                  Praktisch: Diese Skripte arbeiten auch mit eigenen Conf-Dateien in den gezeigten Ordnern - man muss die nur korrekt ablegen.

                  Das ist viel einfacher und klarer, als sich mit einem Editor durch 2000 Zeilen einer monolitischen Config durchzugraben. Und vor allem ist das schneller gemacht, was sich besonders im Fehlerfall als krasser Riesenvorteil erweist.

                  Außerdem kann so für jedes der Apache-Module (Versuche mal apt list libapache2* ... ) die *load bzw. *conf-Datei einfach im Installations-Paket des Moduls geliefert und mit 2 Befehlen aktiviert werden. Dto. die conf-Dateien und die für die „sites", a.k.a. „virtual hosts“.

                  Einfacher, bequemer und zugleich offensichtlicher und durchsichtiger geht es doch kaum...

                  (Rolf2, von weiter oben)

                  Im IIS klickt man das mit 5-10 Mausklicks im IIS Verwaltungstool zusammen und ist fertig

                  Die Anforderungen an die Plausibilität und Erkennbarkeit mancher Vorgänge sind offensichtlich sehr unterschiedlich...

  3. Hello,

    dazu kannst Du dir virtualHosts definieren. Allerdings wird das (ohne Stress) nur auf Port 80 funktionieren.

    Die Domainnamen könnten dann z. B. example.lan für example.com www.example.lan für www.example.com

    usw. heißen. Die "LAN-Namen" trägst Du dann in die lokale Hosts-Datei ein. Je nachdem, ob Linux oder Windows liegt die unterschiedlich im Verzeichnisbaum

    Zur Änderung musst Du bei Windows vermutlich den Editor als Administrator und bei Linux mit sudo (also als Pseudo-Root) aufrufen.

    Wenn Du die virtHost-Records erstellt hast, und die passenden Verzeichnisse dafür angelegt und für Apache freigegeben hast, musst Du den Apache (XAMPP) neu starten, bzw. ein RELOAD für den Service durchführen.

    Mit den genannten Stichworten findest Du alle weiteren Infos in der allewissenden Müllhalde. Sonst melde Dich nochmal.

    Hallo,
    nachdem ich in dem zuständigen Forum leider viele Tips erhalten hatte, die das Problem nicht lösten, hoffe ich, dass hier in dem Forum jemand ist, der auf dem Rechner ein lokales XAMPP erstellt und dann in Apache Domains erfolgreich definiert hat.

    Ich habe XAMPP/Apache erfolgreich installiert. Hat jemand von Euch eine Anleitung, wie ich meine Domains im aktuellen Apache definieren muss, damit ich sie lokal testen kann?

    Glück Auf
    Tom vom Berg

    --
    Es gibt soviel Sonne, nutzen wir sie.
    www.Solar-Harz.de
    S☼nnige Grüße aus dem Oberharz
    1. Hallo,
      ich habe jetzt XAMPP komplett neu installiert und danach folgende Änderungen vorgenommen:
      `######################## .host ###############################

      127.0.0.1 www.MEINBEISPIEL.de
      127.0.0.1 localhost

      ############################# Virtual Hosts ######################

      ##<VirtualHost *:80>
      ##ServerAdmin webmaster@dummy-host2.example.com
      ##DocumentRoot "C:/xampp/htdocs/dummy-host2.example.com"
      ##ServerName dummy-host2.example.com
      ##ErrorLog "logs/dummy-host2.example.com-error.log"
      ##CustomLog "logs/dummy-host2.example.com-access.log" common
      ##</VirtualHost>

      <VirtualHost *:80>
      ServerAdmin webmaster@MEINBEISPIEL.de
      DocumentRoot "D:/Myhompages/MEINBEISPIEL"
      ServerName www.MEINBEISPIEL.de
      ErrorLog "logs/MEINBEISPIEL.log"
      CustomLog "logs/MEINBEISPIEL-access.log" common
      </VirtualHost>

      ############################# Ergebnis in error.log #############
      [Thu Feb 23 14:58:56.065605 2023] [authz_core:error] [pid 10508:tid 1884[client 127.0.0.1:53298] AH01630: client denied by server configuration: C:/xampp/htdocs/favicon.ico, referer: https://www.MEINBEISPIEL.de/ `

      Warum wird favicon auf C:/xampp/htdocs gesucht und nicht in dem von mir angegebenen Verzeichnis?

      1. Warum wird favicon auf C:/xampp/htdocs gesucht und nicht in dem von mir angegebenen Verzeichnis?

        Vermutlich, weil "https://" nicht auf Port 80 läuft.

        1. Warum wird favicon auf C:/xampp/htdocs gesucht und nicht in dem von mir angegebenen Verzeichnis?

          Vermutlich, weil "https://" nicht auf Port 80 läuft.

          Ich habe doch <VirtualHost *:80> angegeben. Muss noch an anderer Stelle geändert werden?

          1. Warum wird favicon auf C:/xampp/htdocs gesucht und nicht in dem von mir angegebenen Verzeichnis?

            Vermutlich, weil "https://" nicht auf Port 80 läuft.

            Ich habe doch <VirtualHost *:80> angegeben. Muss noch an anderer Stelle geändert werden?

            Ja. Gib die Adresse des Favicons an. Sonst sucht der Browser mit HTTPS.

            Ohnehin solltest Du https durch Deaktivieren des ssl-Moduls abschalten und Port 443 somit ebenfalls deaktiveren oder auch einen virtual host auch für Port 443 mit den selben Eigensschaften wie von Dir für Port 80 gezeigt einrichten.

            <VirtualHost *:443>
            …
            
            
            1. Gib die Adresse des Favicons an. Sonst sucht der Browser mit HTTPS.

              Habe ich gemacht, keine Änderung

              Ohnehin solltest Du https durch Deaktivieren des ssl-Moduls abschalten und Port 443 somit ebenfalls deaktiveren

              Leider habe ich nicht gefunden, wo ich dies machen kann

              einen virtual host auch für Port 443 mit den selben Eigensschaften wie von Dir für Port 80 gezeigt einrichten.

              Habe ich gemacht, aber dann kommt der Fehler: `Fehler: Gesicherte Verbindung fehlgeschlagen

              Beim Verbinden mit www.example.org trat ein Fehler auf. SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat.

              Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG`

              1. Leider habe ich nicht gefunden, wo ich dies machen kann

                Und jetzt soll ich es erraten?

                Zeig doch mal Deine httpd.conf, apache2.conf oder wie auch immer dieser XAMPP-Mist die Datei genannt hat. Dort muss es eine Zeile geben, die mit irgend was mit „Module“ und „ssl“ zu tun hat.

                Ebenso sollte was von „Listen 443“ drinstehen

                Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG`

                Ja. Das heißt, Du hast Port 443 offen, der Apache lauscht daran, antwortet aber (mutmaßlich) mit Klartext. Das behauptet die erste Fundstelle bei Tante Google und ich kenne das auch so.

                Dir fehlen für http nämlich noch die Schlüssel-Dateien für den Virtual host.

                Dein Job, denn Du willst einen Webserver betreiben und lernen wie es geht:

                httpd.conf, apache2.conf oder wie auch immer dieser XAMPP-Mist die Datei genannt hat, lesen, Handbuch zu Rate ziehen.

                Hinweis an Dich: Es wäre viel einfacher und lehrreicher XAMPP zu deinstallieren, die Ubuntu-App zu installieren, darin einen Apache mit php und mariadb zu installieren, das Zeug zu konfigurieren und zu benutzen - genau so wie Du das im „richtigen“ Internet machen würdest. Dann musst Du nur noch gurgeln, wo Du unter Windows das Wurzelverzeichnis des vermeintlichen Linux liegen hast. Ist wohl etwas wie (also wahrscheinlich nicht genau)

                C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\
                

                , das im Explorer dann auch gleich bookmarken und kannst von da aus weitermachen, wie in den Linux-Handbüchern beschrieben. (Der Herr sei gepriesen, dass ich mit dem Windows-Mist nichts mehr zu schaffen habe!)

                Freilich kann man auch Docker nehmen… Das ist dann aber eine noch steilere Lernkurve.

                1. Zeig doch mal Deine httpd.conf, apache2.conf oder wie auch immer dieser XAMPP-Mist die Datei genannt hat. Dort muss es eine Zeile geben, die mit irgend was mit „Module“ und „ssl“ zu tun hat.

                  Ebenso sollte was von „Listen 443“ drinstehen

                  #  .....
                  # When we also provide SSL we have to listen to the 
                  # standard HTTP port (see above) and to the HTTPS port
                  #
                  Listen 443
                  
                  ##
                  ## SSL Virtual Host Context
                  ##
                  
                  <VirtualHost _default_:443>
                  
                  #   General setup for the virtual host
                  DocumentRoot "C:/xampp/htdocs"
                  ServerName www.example.com:443
                  ServerAdmin admin@example.com
                  ErrorLog "C:/xampp/apache/logs/error.log"
                  TransferLog "C:/xampp/apache/logs/access.log"
                  
                  </VirtualHost>          
                  
                  

                  Dein Job, denn Du willst einen Webserver betreiben und lernen wie es geht:

                  Ich will keinen Webserver betreiben, am liebsten wäre mir eine Black Box, in der ich meine Anwendungen testen kann. Laut den zahlreichen Beschreibungen ist dies auch einfach mit wenigen Anpassungen zu erreichen. Nur hakt es jetzt wohl an einer Kleinigkeit, die von einem Windows-XAMPP-Kenner sicherlich schnell gefunden würde.

                  Hinweis an Dich: Es wäre viel einfacher und lehrreicher XAMPP zu deinstallieren, die Ubuntu-App zu installieren, darin einen Apache mit php und mariadb zu installieren, das Zeug zu konfigurieren und zu benutzen - genau so wie Du das im „richtigen“ Internet machen würdest. Dann musst Du nur noch gurgeln, wo Du unter Windows das Wurzelverzeichnis des vermeintlichen Linux liegen hast. Ist wohl etwas wie (also wahrscheinlich nicht genau)

                  Ich bezweifle ob ich so rasch mit Ubuntu zurecht kommen würde.

                  1. Ok. Jetzt überlege, was das das macht, ob Du das willst, und warum Du es - falls Du das nicht willst - nicht einfach rauswirfst. (Am besten, weil Du das irgendwann vielleicht wieder anders haben willst) komplett zu Kommentaren machst → die beginnen mit einem #).

                    Den anderen virtual host für port 443 kannst Du auf die selbe Weise kicken.

                    Im Übrigen stehen noch weitere Zeilen zum Thema ssl weiter ober. Da Du das nicht verwenden willst ...

                    Ich will keinen Webserver betreiben, am liebsten wäre mir eine Black Box,

                    Tja. Nur leider willst Du ja eine Testumgebung. Nun mag XAMPP als solche beworben werden - nur ist die Sache eben nicht ganz so einfach. Will man, das die andere Eigenschaften hat und, so weit wie möglich, einem später benutzten Server gleicht, dann kann und muss man das eben anpassen und kommt ergo um das Studium des Handbuches nicht herum.

                    Ich bezweifle ob ich so rasch mit Ubuntu zurecht kommen würde.

                    Nun, man muss es nur wollen. Windows wurde von vielen quasi als das einzige existierende OS betrachtet und deshalb wurden ganze Generationen Unwissender dazu angehalten, das zu benutzen - ich weiß aber, dass ich „den Scheiß“ nicht will. Und vor allem weiß ich auch warum das so ist.

                    1. Ok. Jetzt überlege, was das das macht, ob Du das willst, und warum Du es - falls Du das nicht willst - nicht einfach rauswirfst. (Am besten, weil Du das irgendwann vielleicht wieder anders haben willst) komplett zu Kommentaren machst → die beginnen mit einem #).

                      Den anderen virtual host für port 443 kannst Du auf die selbe Weise kicken.

                      Jetzt geht noch weniger "Verbindung fehlgeschlagen". Und kein Hinweis in den Log-Dateien.

                      Nun, man muss es nur wollen. Windows wurde von vielen quasi als das einzige existierende OS betrachtet und deshalb wurden ganze Generationen Unwissender dazu angehalten, das zu benutzen - ich weiß aber, dass ich „den Scheiß“ nicht will. Und vor allem weiß ich auch warum das so ist.

                      Mag ja sein, dass Du den Sch... nicht willst. Allerdings gibt es offensichtlich weltweit viel mehr Unwissende als Wissende, wie Du. Ich hoffe, dass sich unter diesen jemand findet, der sich in Windows besser auskennt als Du und mir weiterhelfen kann. Trotzdem Dank für Deine Bemühungen.

                      1. Ok. Jetzt überlege, was das das macht, ob Du das willst, und warum Du es - falls Du das nicht willst - nicht einfach rauswirfst. (Am besten, weil Du das irgendwann vielleicht wieder anders haben willst) komplett zu Kommentaren machst → die beginnen mit einem #).

                        Den anderen virtual host für port 443 kannst Du auf die selbe Weise kicken.

                        Jetzt geht noch weniger "Verbindung fehlgeschlagen". Und kein Hinweis in den Log-Dateien.

                        Also erst willst Du kein HTTPS, dann meckerst Du, wenn es nicht geht. (Und Du kannst in dieser Konstellation kein funktionierendes HTTPS hinbekommen, jedenfalls nicht ohne eine eigene PKI, die nochmal ein Buch für sich ist.)

                        Die für Dich geltende Lösung ist also:

                        Rufe Deine Webseite mit vollständiger URL auf, lass den Browser nichts erraten:

                        • http://dummy-host2.example.com/

                        Vergiss das http:// nicht. Sonst schreibt jeder halbwegs moderne Browser hinter Deinem Rücken httpS:// davor - was Du ja nicht willst.

                        1. Die für Dich geltende Lösung ist also:

                          Rufe Deine Webseite mit vollständiger URL auf, lass den Browser nichts erraten:

                          • http://dummy-host2.example.com/

                          Vergiss das http:// nicht.

                          Das ist leider auch nicht die Lösung, da http://dummy-host2.example.com/ umgewandelt wird in https://dummy-host2.example.com/

                          und zwar nicht durch mich in .htaccess oder an anderer Stelle.
                          Offensichtlich machen dies laut Internet-Recherche die Browser.

                          1. Offensichtlich machen dies laut Internet-Recherche die Browser.

                            Im konkreten Fall (wohl) nur, weil Du vorher „herumgespielt“ hast und der Browser vermeint, dass es https://dummy-host2.example.com:443/ etwas verschlüsselt abholbares gäbe. Was aber nicht mehr der Fall ist.

                            Kannst Du http://dbinterface.de aufrufen?

                            Ja: Dann lösche den Cache für gesamte Domain dummy-host2.example.com (oder meinetwegen den gesamten Cache) und starte den Browser neu. Oder versuche ein „privates Fenster“. Wie das geht steht im Handbuch Deines Browsers.

                            Nein: Jemand (vermutlich Du selbst) hat den Browser so konfiguriert, dass er unverschlüsselten Transport nicht mehr akzeptiert. Wie Du (oder wer auch immer) das gemacht hast steht im Handbuch Deines Browsers.

                          2. Hello,

                            Die für Dich geltende Lösung ist also:

                            Rufe Deine Webseite mit vollständiger URL auf, lass den Browser nichts erraten:

                            • http://dummy-host2.example.com/

                            Vergiss das http:// nicht.

                            Das ist leider auch nicht die Lösung, da http://dummy-host2.example.com/ umgewandelt wird in https://dummy-host2.example.com/

                            und zwar nicht durch mich in .htaccess oder an anderer Stelle.
                            Offensichtlich machen dies laut Internet-Recherche die Browser.

                            Das gilt aber mMn nur für bekannte TLDs. Für die reserverten TLDs, z. B. *.local oder das von mir vorgeschlagene *.lan wird nicht im Internet gesucht und daher das vorgegebene Scheme nicht von http zu https expandiert.

                            Glück Auf
                            Tom vom Berg

                            --
                            Es gibt soviel Sonne, nutzen wir sie.
                            www.Solar-Harz.de
                            S☼nnige Grüße aus dem Oberharz
                            1. Das gilt aber mMn nur für bekannte TLDs. Für die reserverten TLDs, z. B. *.local oder das von mir vorgeschlagene *.lan wird nicht im Internet gesucht und daher das vorgegebene Scheme nicht von http zu https expandiert.

                              Womöglich doch. Wenn eine URL auch dieser TLDS in die Chronik geraten ist, wird diese via Bedienfehler(sic:Bedienfehler) durch das Einschlagen auf die [ENTER]-Taste in die Adresszeile übernommen. Da muss man dann schon sehr genau tippen…

                              1. Hello,

                                Das gilt aber mMn nur für bekannte TLDs. Für die reserverten TLDs, z. B. *.local oder das von mir vorgeschlagene *.lan wird nicht im Internet gesucht und daher das vorgegebene Scheme nicht von http zu https expandiert.

                                Womöglich doch. Wenn eine URL auch dieser TLDS in die Chronik geraten ist, wird diese via Bedienfehler(sic:Bedienfehler) durch das Einschlagen auf die [ENTER]-Taste in die Adresszeile übernommen. Da muss man dann schon sehr genau tippen…

                                und vergessen habe ich dabei, dass die TLDs bei den Google-infizierten Browsern durchprobiert werden, wenn es öffentliche sind. Aus einem nichtauflösbaren example.de wird dann schell ein example.com.

                                Glück Auf
                                Tom vom Berg

                                --
                                Es gibt soviel Sonne, nutzen wir sie.
                                www.Solar-Harz.de
                                S☼nnige Grüße aus dem Oberharz
                  2. Ich will keinen Webserver betreiben, am liebsten wäre mir eine Black Box, in der ich meine Anwendungen testen kann.

                    Vielleicht willst Du am Ende des Tages auf Deinem Live-System einfach nur einen "/test/"-Ordner anlegen? Hint: diesen per robots.txt dann vom Crawlen ausnehmen, ober, besser noch: via HTAUTH absichern.

                    1. Ich will keinen Webserver betreiben, am liebsten wäre mir eine Black Box, in der ich meine Anwendungen testen kann.

                      Vielleicht willst Du am Ende des Tages auf Deinem Live-System einfach nur einen "/test/"-Ordner anlegen? Hint: diesen per robots.txt dann vom Crawlen ausnehmen, ober, besser noch: via HTAUTH absichern.

                      Hm.

                      Ich bin mir jetzt absolut nicht im Klaren, wie das dem TO helfen soll. Erläutere doch bitte, welches Problem des TO hiervon wie berührt oder gar gelöst wird.

                      1. Ich will keinen Webserver betreiben, am liebsten wäre mir eine Black Box, in der ich meine Anwendungen testen kann.

                        Vielleicht willst Du am Ende des Tages auf Deinem Live-System einfach nur einen "/test/"-Ordner anlegen? Hint: diesen per robots.txt dann vom Crawlen ausnehmen, ober, besser noch: via HTAUTH absichern.

                        Ich bin mir jetzt absolut nicht im Klaren, wie das dem TO helfen soll. Erläutere doch bitte, welches Problem des TO hiervon wie berührt oder gar gelöst wird.

                        Wenn der OP sich schwer mit Einrichtung eines kompletten Testservers tut, dann könnte die Verwendung eines "Test-Ordners" im Live-System evtl. ja schon ausreichen.