Das längste Thema

  • Ich glaube, ich habe einen Bug in Chrom(e|ium) gefunden… :|


    Links die übertragenen Daten (laut Entwicklertools und cURL) – rechts die Quelltextansicht vom Browser:


    Bildschirmfoto_2018-09-10_14-16-59.png


    Es ist immer die gleiche und einzige Position, wo das & verunstaltet wird. Ändert man serverseitig den Inhalt, damit ein paar Byte mehr oder weniger davor vorkommen, verschwindet die Verunstaltung meistens, manchmal taucht allerdings eine zweite &aamp; Stelle auf. Es handelt sich dabei um ca. 75KB HTML-Code mit knapp 10.000 Zeilen.


    WTF‽

  • Hay,

    6 Jahre alten Code

    tut mir leid. Ich habe gerade soooo lachen müssen. 6 Jahre... 2012 also... ich habe gerade ein Softwareprodukt (Client/Server) übernommen, das aus der Zeit stammt und es handelt sich um (undokumentierten) Code eines Schweden, der seine Variablen auch teils schwedisch benannt hat. Und es sind große Fehler drin. Das zählt für mich noch als "neuer Code".


    Ich habe die letzten drei Tage (plus die nächsten drei) mit Code gearbeitet, den ich 1990 in Turbo Pascal geschrieben habe, 2003 auf PHP3 umgesetzt habe (dann PHP4 und PHP5) und ich bin gerade dabei "alles" zu modernisieren und auf PHP7 umzusetzen (d.h. lief natürlich schon unverändert unter PHP7, aber ohne dessen Neuerungen zu nutzen). Fehler kamen nur durch Versionswechsel des Unterbaus (parallel dazu kams ja noch zu neuen Versionen von HTML, CSS, Javascript inkl. der teilweise harten Dogmenwechsel).


    Ein paar zentrale Teile sind immer noch original 1990 (nur auf die andere Sprachsyntax umgestellt) und die fasse ich einfach nicht mehr an :D Sogar das mega-effizente (Kern-)Datenformat, was ursprünglich flat-file auf Diskette (!!) vorlag, blieb bis auf die Umwandlung von sequenziellem File zu relationaler MySQL Datenbank gleich und liegt (ein Items pro Datensatz) in einem großen Textfeld. Das Textfeld ist schneller in PHP dekomprimiert als in entsprechende relationale Datenbankaufrufe umgesetzt und von Datenbank geladen. Das Handling im Client ist kompliziert, wenn Daten verändert werden müssen.Wirklich nicht modern, das darf ich eigentlich keinem zeigen... aber mir kam gerade der Gedanken, dass ich es mittlerweile als json-Objekt ablegen könnte (um es mal so zu sagen: jetzt gebräuchliche Datenformate nähern sich meinen alten an), dann siehts wenigstens "stat-of-the-art" aus. Wäre aber dann schon langsamer 8o


    An anderer Stelle arbeite ich mit Visual-Basic Code, der frisch war, als Access 97 auch noch neu war - und musste deswegen für den Kunden Access 97 jetzt auf Windows 10 lauffähig bekommen, statt dass er einmal richtig Geld in die Hand nimmt und es auf ein aktuelles Access umsetzen lässt (oder nach meinem Wunsch auf eine originäre Webanwendung).


    CU, Peter

  • Der grundlegende Angriff ist seit Jahren bekannt. Und trotzdem deployen nicht mehr Leute DNSSEC. Dann wäre das nur heiße Luft und sonst nichts.

    Warum steht das eigentlich nicht auf default? meines Wissens nach genügt es doch den Haken zu setzen, oder übersehe ich das was?

  • DNSSEC

    Warum steht das eigentlich nicht auf default?

    weil es wie alle neuen Technologien noch nicht wirklich ausgegoren ist, und es evtl. auch zu Problemen führen kann: client-seitig;

    (in dem Fall heißt das Problem gar keine DNS-Auflsg.)


    und das Feature DANE/TLSA, welches ja DNSSEC voraussetzt ist noch weniger verbreitet; und das auch zu Recht;

    ich kenne keinen Browser, Mail-Agent, ... der hier ein echtes 'hardfail' veranstaltet; und Dank des Umstandes daß allen voran Mozilla Schnittstellen ändert wie andere ihre Unterhosen; verstehe ich auch die Argumentation der nic.cz, welche f. FF/GC/IE das Plugin TLSAValidator gestrickt hat, und dieses mangels Bestand der Schnittstelle f. Mozilla einfach nur zaghaft weiterentwickelt - die letzten beiden Releases sind vom Feb 2017 bzw. Sept 2014;


    anscheinend ist hier Mozilla der Elephant im Porzellanladen; die IETF selbst ist ebenfalls an der gesamten Entwicklung nicht unschuldig; dort macht sich eine WG - wohlgemerkt die Schöpfer vom heftig umstrittenen TLS1.3¹ und unausgegorenem HTTP/2² - ob man nicht die ganze Client-Config wie: Display, Standort (GPS), ... per HTTP-Header zum Web-Server bei jedem Request jagt ...


    ¹ sind hier nicht Dinge wie Backdoors f. die NSA mit an Board?

    ² ein clientseitiger Support, der nur über TLS gegeben ist, nur um Features zu haben, welche Apache schon seit Jahren

    mit HTTP/1.1 unterstützt - Stichwort: KeepAlive, aber man aus gutem Grund lieber nicht aktiviert ...

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Die beschissenere Technologie setzt sich doch meistens durch... z.B. Verbrennungsmotor, VHS, Windows...

    wie soll sich IPv6 denn durchsetzen, wenn z.B. Android es nicht mal im Jahr 2018 geschafft hat, vollständig zu unterstützen?

    es kennt einzig nur SLAAC; genau wie mein doch etwas älterer Drucker mit Netzwerkinterface; bei Mobilgeräten verstehe ich es ja noch, aber bei z.B. Geräten, die man üblicherweise per DNS anspricht, absolut nicht;

    habe daher auf meinem Drucker IPv6 abgedreht;

    auch ist SLAAC selbst sehr strikt definiert; es kann nicht auf kleinere Prefixe als /64 definiert werden;

    (es würde ja doch Sinn machen, z.B. zu Hause od. auch Small-Offices SLAAC vergebene Adressen nur in einem /80-Teil des gesamten /64-Prefixes zu haben - geht aber nicht)


    stateless DHCPv6 (= SLAAC) vs. statefull DHCPv6 ist auch ein Kapitel f. sich - ich hab zu Hause eine Mischform;

    (in der radvd.conf habe ich in der clients-section Scope:Local Adressen die erlaubt sind, und in der dhcpd6.conf weise ich die DNS-Server zu)


    IoT der Unfug schlechthin; wieso muss - nur weil man eine Technologie nutzt, die man auch im Internet hat (z.B. Adressierung, Übetragungsprotokolle) - eine Verbindung auch zum Internet bestehen?

    Atomkraftwerke, Kirchturmglocken, Zutrittsysteme ...
    daß man es eben nicht kann sieht man an den Hackangriffen, welche ja nur dadurch ermöglicht werden ...

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Die Frage ist doch, was noch gegen http/2 spricht. Ich lese da jedenfalls keine Gründe aus deinem Post heraus, die das sagen. Http/2 wird mittlerweile von diversen großen Webseiten (google, facebook, twitter, github etc.) verwendet und dürfte so stabil sein, dass man es problemlos produktiv einsetzen kann.


    Ein Zertifikat sollte man doch mittlerweile sowieso haben, denn die Seite wird ja ohne als "nicht sicher" angezeigt, was schon mal beim Besucher keinen guten Eindruck hinterlässt. Dann soll es ja auch negative Auswirkungen auf das page ranking haben, wenn man kein https verwendet.


    War keepalive nicht eine Apache eigene, nicht standardisierte Lösung?

  • mainziman Lass uns dieses Thema hier weiterführen wegen OT:

    wie hat er dann Zugriff auf das DNS der Domain des Dienstleisters?

    (das wäre aber notwendig beim DNS-Challenge)

    Wieso das? Er validiert seine Domain, ob der dahinter liegende Record ein CNAME ist oder nicht, ist ACME vollkommen egal. Für die Validierung erstellst du einen TXT-Record unter der ursprünglich zu validierenden Domain.

  • Die Frage ist doch, was noch gegen http/2 spricht. Ich lese da jedenfalls keine Gründe aus deinem Post heraus, die das sagen. Http/2 wird mittlerweile von diversen großen Webseiten (google, facebook, twitter, github etc.) verwendet und dürfte so stabil sein, dass man es problemlos produktiv einsetzen kann.


    Ein Zertifikat sollte man doch mittlerweile sowieso haben, denn die Seite wird ja ohne als "nicht sicher" angezeigt, was schon mal beim Besucher keinen guten Eindruck hinterlässt. Dann soll es ja auch negative Auswirkungen auf das page ranking haben, wenn man kein https verwendet.


    War keepalive nicht eine Apache eigene, nicht standardisierte Lösung?

    Keine Ahnung, was je dagegen sprach. Nutze ausschließlich http2 seit Jahre, seit der Implementierung in die mainline Version von nginx. Wobei es mir auch relativ egal ist, ob meine Seiten zu 100% von allen erreichbar sind 😂😂

  • War keepalive nicht eine Apache eigene, nicht standardisierte Lösung?

    das kommt bei der Suche danach nicht wirklich zum Vorschein,


    ABER:

    https://en.wikipedia.org/wiki/HTTP_persistent_connection

    zeigt unter den Nachteilen etwas auf, das ja bei HTTP/2 ebenfalls ist;

    und ohne dieser HTTP_persistent_connection macht HTTP/.2 eigentlich keinen Sinn;

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Naja die Server werden schon irgend einen timeout haben, nachdem sie dann die Verbindung schließen. Ich kann mir halt nicht vorstellen, dass das noch ein Problem darstellt, wenn Seiten, mit Millionen Zugriffen pro Monat http/2 verwenden.


    https://http2.github.io/faq/ liefert eine schöne Übersicht, was http/2 alles kann. Das ist weit mehr als nur eine Verbindung für mehrere Requests zu verwenden.

  • Keine Ahnung, was je dagegen sprach. Nutze ausschließlich http2 seit Jahre, seit der Implementierung in die mainline Version von nginx. Wobei es mir auch relativ egal ist, ob meine Seiten zu 100% von allen erreichbar sind 😂😂


    Wobei es eher unwahrscheinlich ist, dass wegen http/2 jemand die Seite nicht öffnen kann, da ja die Webserver automatisch auf http/1.1 zurückfallen, wenn der Client kein http/2 unterstützt. Manche Bots, die meine Seite crawlen verwenden scheinbar nur 1.1, die können aber die Seiten trotzdem abrufen, da erscheint dann im access.log, dass der Zugriff über http 1.1 erfolgte.

  • mainziman Lass uns dieses Thema hier weiterführen wegen OT:

    Wieso das? Er validiert seine Domain, ob der dahinter liegende Record ein CNAME ist oder nicht, ist ACME vollkommen egal. Für die Validierung erstellst du einen TXT-Record unter der ursprünglich zu validierenden Domain.

    Beispiel:

    wenn ich bei meiner Domain (example.com) das da mach


    hugo CNAME hugo.3rdparty.com


    und ich ein SSL-Zertifikat haben will,

    dann muss sowohl hugo.example.com als auch hugo.3rdparty.com validiert werden,

    zumal sowohl hugo.3rdparty.com als auch der DNS-Alias hugo.example.com auf den identen Webspace zeigen;

    auf das von 3rdparty.com hast Du aber keinen Zugriff, auf den Webspace aber schon ...


    wobei das mit dem d.zkr.io ist mir irgendwie suspekt;

    man sehe sich zkr.io d.zkr.io cdn.zkr.io an ...

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • Die Frage ist doch, was noch gegen http/2 spricht.

    an Hand der Tatsache, daß es client-/browserseitig nur mit TLS unterstützt wird, doch einiges;


    SSL Everwhere ist nett, aber problematisch wenn nicht sogar umstritten gleichzeitig;


    - IPv4 Adressen sind knapp und SNI kann nicht überall eingesetzt werden,

    der Workaround IPv6 hat keine hinreichende Verbreitung;

    - ein erhöhter Resourcenverbrauch bedingt durch CPU-Last und RAM-Auslastung:

    vor mehreren Jahren galt daß f. die Aufrechterhaltung der weltweiten Infrastruktur nur f. E-mail

    das Energie-Äquivalent¹ von 4000 Flügen einer Boeing 747 von Paris nach New York notwendig ist;

    wieviele Flüge dürfen f. SSL Everwhere angesetzt werden?

    - erschwerte bzw. unmögliche Unterscheidung zwischen wichtig/unwichtig bzw. kritisch/unkritisch f. Otto-Normaluser,

    wenn es denn mal seltsame Fehler liefert ob man es denn umgehen kann/darf;


    ¹ in den USA gibt es Gebirgskette, welche durch den Kohleabbau im Tagbau derart verändert wurde,

    daß das Landschaftsbild größeren Ausmaßes umgestaltet wurde; ob positiv od. negativ sei mal dahingestellt;

    (der Kohlenstrom floß/fließt 1:1 in ein/mehrere Datacenter von Facebook, Google, ...)

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%