Moin, heute habe ich auf FF 83 "geupdatet", seitdem funktionieren meine lokalen Webseiten nicht meht. FF meint, "Die Verbindung mit dem Server www.server.com schlug fehl.". Unmittelbar vorher funktionierte nach noch alles. Ich rufe die Seite mit zB "<a target="blank" ref="http://server/rb">MurxVonMarx"; auf. Bisher probiert: network.dns.disablePrefetch auf true Mit IE funktioniert alles. Übers Web lassen sich die nach außen freigegeben Seiten aufrufen, der Indianer dürfte daher unschuldig sein, in den Logfiles ist schlicht nichts ... Bein Aufruf fügt der FF anscheinend ein ".com" an den Servernamen und findet den dann natürlich nicht. Davor schreibt er "www.". Ich kann mich nicht dran erinnern, daß das vorher schon war. Wie komme ich da weiter ? Was haben die da wieder geändert ? Hausintern habe ich kein https, wozu auch ... (es heißt natürlich href, nicht ref. Forum meint, das sei Spam, das /a mag es auch nicht)
Beitrag #6479899 wurde von einem Moderator gelöscht.
Joachim D. schrieb: > "<a target="blank" ref="http://server/rb">MurxVonMarx";; - Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen aussieht. Bei Fritzens ist fritz.box voreingestellt. - Stell sicher, dass FF kein DNS-over-HTTPS verwendet. - Notfalls schreibst du den Namen in die Hosts Datei rein: \windows\system32\drivers\etc\hosts
Vielen herzlichen Dank ! Ich habe Servername und IP in C:\Windows\System32\drivers\etc\hosts eingetragen und er findet das wieder, alles ok !
(prx) A. K. schrieb: > Joachim D. schrieb: >> "<a target="blank" ref="http://server/rb">MurxVonMarx";;; > > - Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen > aussieht. Bei Fritzens ist fritz.box voreingestellt. Oder einfach .local > - Stell sicher, dass FF kein DNS-over-HTTPS verwendet. > > - Notfalls schreibst du den Namen in die Hosts Datei rein: > \windows\system32\drivers\etc\hosts Joachim D. schrieb: > Bein Aufruf fügt der FF anscheinend ein ".com" an den > Servernamen und findet den dann natürlich nicht. Davor > schreibt er "www.". Ich kann mich nicht dran erinnern, daß > das vorher schon war. Doch, diesen Blödsinn macht er schon lange, aber eigentlich erst, nachdem er es so wie es eingegeben war erfolglos versucht hat. Wenn ich bei mir http://server eingebe, sucht er erwartungsgemäß eine Weile rum, ersetzt dann den Text im Eingabefeld durch www.server.com und meldet dann, dass er das nicht finden kann. Das regt mich schon läger auf. Wenn man da einen lokalen Namen eingibt, aber das Ziel gerade noch nicht verfügbar ist, muss man erstmal den von Firefox kaputtgemachten Text im Eingebefeld reparieren, bevor man es nochmal versuchen kann.
Tja, merkwürdig. In der Fritte lauert ein DNS-Server, der PC kann auf den Webserver zugreifen, sogar der Windows-Explorer. Nur der FF kocht da sein eigenes Süppchen ;(
Gast
#6480239
Es ist nur eine Frage der Zeit, bis folgendes zum default wird: https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ Das wird dann lustig. Dann muss man sich entweder Zuhause mit selbst signierten Zertifikaten herumschlagen, oder braucht ne richtige Domain mit richtigem Zertifikat. Und wetten, dass danach bald darauf LetsEncrypt anfangen wird, für die Zertifikate Geld zu verlangen?
🐧 DPA 🐧 schrieb: > Es ist nur eine Frage der Zeit, bis folgendes zum default wird: > https://blog.mozilla.org/security/2020/11/17/firefox-83-introduces-https-only-mode/ Wenn Du Dir das genauer durchliest, wirst Du feststellen, daß Dich das nicht daran hindert, explizit HTTP-Seiten mit einer "http://..."-URL aufzurufen. Es wird ab dann nur versucht standardmäßig https zu verwenden und bringt bei http eine Warnung. > Und wetten, dass danach bald darauf LetsEncrypt anfangen wird, für die > Zertifikate Geld zu verlangen? Genau, und die Echsenwesen übernehmen bald die Regierung. Das Problem des TO hat nichts mit https oder Zertifikaten zu tun (oder Verschwörungen). Das Problem ist/war die Adressierung. Ich denke es fehlt ein Domainname, wie auch A.K. schon meinte. Man sollte die URL immer mit einem FQDN aufbauen, auch im lokalen Netz. Auf die Domain zu verzichten und zu hoffen, daß der Rechner implizit den richtigen Domainnamen ergänzt, ist ein Spiel mit dem Feuer.
Klar. Ich bewege mich in meinem LAN und brauche dazu eine Domain. Das ist doch total abgedreht ;(
Gast
#6480883
Rolf M. schrieb: > (prx) A. K. schrieb: >> Joachim D. schrieb: >>> "<a target="blank" ref="http://server/rb">MurxVonMarx";;;; >> >> - Lass dir eine lokale Domain einfallen, damit das nach einem DNS-Namen >> aussieht. Bei Fritzens ist fritz.box voreingestellt. > > Oder einfach .local Die korrekte Domain für lokale Netzwerke ist home.arpa. : https://tools.ietf.org/html/rfc8375 .local ist für lokales mdns (bonjour/avahi/etc.) reserviert. Man sollte es nicht als DNS domain für das lokale netz verwenden. Ausserdem war .local ursprünglich für link lokale Adressen gedacht: https://tools.ietf.org/html/rfc6762#section-3
🐧 DPA 🐧 schrieb: > Die korrekte Domain für lokale Netzwerke ist home.arpa. : > https://tools.ietf.org/html/rfc8375 Nett. Jetzt müsste man nur noch eine Installation finden, die sich daran hält. Wobei ich beim darin referenzierten RFC7788 nicht sicher bin, ob das nicht die gleiche Kategorie fällt, wie der RFC1149.
Gast
#6480984
(prx) A. K. schrieb: > 🐧 DPA 🐧 schrieb: >> Die korrekte Domain für lokale Netzwerke ist home.arpa. : >> https://tools.ietf.org/html/rfc8375 > > Nett. Jetzt müsste man nur noch eine Installation finden, die sich daran > hält. Wobei ich beim darin referenzierten RFC7788 nicht sicher bin, ob > das nicht die gleiche Kategorie fällt, wie der RFC1149. Ich habe diese leider auch noch niemand anderen verwenden gesehen. Ein Schertz ist es aber nicht. Die Domain ist auch bei der IANA als special use domain vermerkt: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml Ausserdem braucht man die Domain zwingend, wenn man lokal auf dem PC DNSSEC prüft, und keine eigene Domain hat, aber trotzdem per DNS auf lokale Geräte zugreifen will. Zugegebenermassen scheint das auch keiner zu machen, wobei ich aber hoffe, dass sich das noch ändert, und sich DNSSEC und DANE vielleicht doch noch durchsetzen...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.