pl: Schlanke Alternative zu multipart/form-data

problematische Seite

Hi,

die Abende werden länger und da fällt mir immer mal was ein, z.B. sowas. Es ist an der Zeit über neue Content-Types nachzudenken.

Viel Spaß beim Lesen.

  1. problematische Seite

    Hallo pl,

    interessant. An welchen Stellen haben deine Messungen welchen Performancegewinn ergeben?

    Rolf

    -- sumpsi - posui - clusi
    1. problematische Seite

      Benchmark serverprozess

      Rate formdata binary formdata 20.4/s -- -90% binary 213/s 943% --

      Faktor > 10 😉

      Und da hab ich schon den schnellsten Parser genommen. MfG

      1. problematische Seite

        Ergänzung:

        Und da hab ich schon den schnellsten Parser genommen. MfG

        Gegenüber dem Parsen mit legacy CGI.pm ergibt sich ein Geschwindigkeitszuwachs um das 200fache!

        Freundschaft 😉

    2. problematische Seite

      Moin,

      interessant. An welchen Stellen haben deine Messungen welchen Performancegewinn ergeben?

      Im Browser stehen die Erzeugung eines FormData-Objekts oder eines Blob-Objekts zur Disposition. Da dürfte wohl hinsichtlich der Performance kaum ein Unterschied bestehen.

      Der mit FormData erzeugte UploadStream ist nur unwesentlich länger als die als Blob gesendete Binary. Auch hier gibt es wohl kaum Unterschiede die exakt erfasst werden könnten.

      Interessant wird es jedoch serverseitig. So ist das Parsen eines FormData-Body sehr CPU-lastig und speicherfressend, je nachdem wie der Parser arbeitet. Je nach Parser werden auch temporäre Dateien angelegt die ein Sicherheitsrisiko darstellen können.

      Der Hauptgewinn gegenüber multipart/form-data ergibt sich somit daraus daß der Upload-Stream nicht geparst werden muss. Der serverseitige Prozess begnügt sich damit, die Binary nur zu lesen anhand der mitgelieferten Längenangaben wobei mit dem Lesen unmittelbar begonnen werden kann (streaming).

      MfG

      1. problematische Seite

        Mir ist es ehrlich gesagt zu müßig, auf die Nummer einzugehen. Ausnahme:

        Interessant wird es jedoch serverseitig. So ist das Parsen eines FormData-Body sehr CPU-lastig und speicherfressend, je nachdem wie der Parser arbeitet. Je nach Parser werden auch temporäre Dateien angelegt die ein Sicherheitsrisiko darstellen können.

        Zitat:

        my @names = $self->param('name'); while( my($i, $len) = each @lens){ my $name = $names[$i]; $fh->open( "d:/tmp/$name", O_CREAT|O_BINARY|O_TRUNC|O_RDWR ) or die $!; }

        Sieht mir schwer nach Sicherheitsrisiko aus. Außer, Du machst vorher eine nicht weiter erwähnte Magie auf $self->param('name'). Solltest Du dann aber dazuschreiben. So ist das eine böse Lücke und keine gute Empfehlung.

        1. problematische Seite

          Danke für den Hinweis, ich habe die Datei-Namen rausgenommen damit das nicht weiter verwirrt. MfG

  2. problematische Seite

    Hi,

    für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet. Die einzelnen Längenangaben werden über einen custom Header mitgeschickt.

    MfG

    1. problematische Seite

      für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet.

      Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

      Folgende Nachrichten verweisen auf diesen Beitrag:

      1. problematische Seite

        für's Download ist dieses Verfahren natürlich auch zu gebrauchen. Die Images werden serverseitig aneinandergehängt und als eine binary gesendet.

        Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

        Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

        1. problematische Seite

          Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

          Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

          Komische Antwort in Zeiten, in denen sich HTTP/2 immer weiter durchsetzt 😀

          Das bringt den von Dir skizzierten Vorteil und noch eine ganze Menge mehr.

          Im Gegensatz zu Deinem propietären Vorschlag ist HTTP/2 ein definierter Standard, der ohne eigene Implementationen im Client / Server einfach funktioniert.

          Du musst einen (immer teuren) Scriptprozess starten, um die Ressourcen zusammenzupacken... wenn der Client immer einen großen Blob statt z.B. 10 Bildreferenzen vor den Latz geknallt bekommt, sind die Bilder nicht mehr einzeln adressierbar... Lazy Loading fällt flach... usw...

          Fazit: Dein Vorschlag bringt viele Nachteile mit sich. Der von Dir skizzierte Vorteil ist mit HTTP/2 keiner mehr.

          Daher nochmals meine kleine Nachfrage: warum?

          1. problematische Seite

            Superkrasse Sache! Ich habe da nur eine kleine Nachfrage: warum?

            Mehrere Dateien in einem einzigen Request/Response Zyklus übertragen? Komische Frage im Zeitalter von Multimedia 😉

            Komische Antwort in Zeiten, in denen sich HTTP/2 immer weiter durchsetzt 😀

            Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

            1. problematische Seite

              Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

              Kleine Nachfrage: warum sollte man das so tun wollen?

              1. problematische Seite

                Na, was glaubst Du wohl, wie HTTP/2.0 funktioniert!? Da sind nur die Längenangaben woanders kodiert ansonsten sind die Bodies genauso aneinandergehängt wie in meiner Demo. Nur kriegste das mit FetchAPI nicht wieder auseinander weil es das Body-Objekt nicht hergibt. MfG

                Kleine Nachfrage: warum sollte man das so tun wollen?

                Der Sinn von HTTP/2 besteht darin, die Anzahl der Requests zu verringern. Insofern gibt es keinen Unterschied zu meiner Demo: Anstatt für 3 Images 3 Requests zu feuern ist nur noch ein Request erforderlich. Ebenso wie bei HTTP/2 muss eine solche Vorgehensweise serverseitig unterstützt sein und auch das Protokoll muss bestimmte Voraussetzungen bieten. HTTP ist grundsätzlich zur Übertragung beliebiger Bytesequenzen geeignet weil es einen Headerblock voranstellt um dem Empfänger mitteilen zu können was er überhaupt zu tun hat mit dem nachfolgenden Content.

                Somit ist der wichtigste Header derjenige welcher den Content-Type angibt. Wenn der z.B. application/pdf lautet, lädt der Browser (falls vorhanden) den PDF Betrachter und der stellt anhand der Binary Texte mit Bildern dar ohne die Bilder vom Server nachladen zu müssen. Genauso können wir uns das bezüglich HTTP/2 vorstellen, nur daß hier der Browser selbst den Inhalt darstellt -- Texte, Bilder, Audio, Video und das alles ohne weitere Requests auf die einzelnen Mediatypen.

                MfG

                1. problematische Seite

                  Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉

                  Der Sinn von HTTP/2 besteht darin, die Anzahl der Requests zu verringern.

                  Nicht nur, aber nehmen wir der Einfachheit halber mal an, es wäre der einzige Vorteil.

                  Insofern gibt es keinen Unterschied zu meiner Demo: Anstatt für 3 Images 3 Requests zu feuern ist nur noch ein Request erforderlich.

                  Insofern kannst Du das schon so sagen. Nur hast Du gleichzeitig eine Menge Nachteile gegenüber HTTP/2 im Gepäck. Beispiele:

                  • die Ressourcen können nicht mehr einzeln gecached werden
                  • du benötigst einen teuren Scriptprozess, um die Ressourcen serverseitig zusammenzupacken
                  • Bilder / Videos sind nicht mehr einzeln adressierbar
                  • ...

                  Ebenso wie bei HTTP/2 muss eine solche Vorgehensweise serverseitig unterstützt sein und auch das Protokoll muss bestimmte Voraussetzungen bieten.

                  Ja. Beinahe alle gängigen Clients können heute schon HTTP/2, einfach so. Wenn ich (du/er/sie/es) dann irgendwann auf dem Server HTTP/2 implementiere(aktiviere), dann funktioniert das. Einfach so!

                  Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren, die zwar das Ziel, mehrere Ressourcen mit einem Request zu übertragen ebenfalls erreicht, bezahlst das aber im Vergleich zu HTTP/2 mit heftigen Nachteilen.

                  Das bring mich zu meiner Eingangsfrage zurück: warum?

                  1. problematische Seite

                    Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉

                    Du hast meine Antwort nicht verstanden.

                    Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren,

                    Nein eben nicht stattdessen. Meine Demo zeigt lediglich wie man mehrere legacy responses in einer response zusammenfassen kann. Das konnte ich Dir übrigens vor 10 Jahren schon zeigen 😉

                    MfG

                    PS: FetchAPI kann übrigens formData() als Response Demo auch damit ist multipart Content möglich -- Nicht proprietär.

                    1. problematische Seite

                      Zunächst einmal hast Du meine letzte Frage (warum sollte man eine HTTP/2 Response via Fetch auseinander dröseln wollen) nicht beantwortet, aber egal 😉

                      Du hast meine Antwort nicht verstanden.

                      OK!

                      Du schlägst nun vor, stattdessen eine propietäre Logik im Client und Server zu implementieren,

                      Nein eben nicht stattdessen. Meine Demo zeigt lediglich wie man mehrere legacy responses in einer response zusammenfassen kann. Das konnte ich Dir übrigens vor 10 Jahren schon zeigen 😉

                      Ah... Du wolltest lediglich sagen: Hey, gäbe es heute kein HTTP/2 und man wollte trotzdem in einer Response mehrere Ressourcen an den Client senden und dabei diverse Nachteile in Kauf nehmen, dann könnte man es genauso machen, wie ich es vor 10 Jahren schon gemacht habe!

                      Habe ich es jetzt richtig verstanden?

                      1. problematische Seite

                        hi,

                        Ah... Du wolltest lediglich sagen: Hey, gäbe es heute kein HTTP/2 und man wollte trotzdem in einer Response mehrere Ressourcen an den Client senden und dabei diverse Nachteile in Kauf nehmen, dann könnte man es genauso machen, wie ich es vor 10 Jahren schon gemacht habe!

                        Habe ich es jetzt richtig verstanden?

                        Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln. Auch das grottige FormData-Objekt muss dafür herhalten -- weils halt mittlerweile damit geht. Auf der MDN Seite hahmse noch kein Beispiel, ich hab eins. Im Gegensatz zu anderen Body-Methods wie text(), arrayBuffer(), blob() interessiert sich die Methode formData() nunmehr für den Response-Header Content-Type samt boundary.

                        Der Zeit immer ein Stück voraus, MfG

                        1. problematische Seite

                          Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln.

                          Wie @Mitleser schon sagte, gibt es nicht das eine Prinzip hinter HTTP/2, sondern eine Menge neuer Features. Mir ist nicht klar, welches Feature von HTTP/2 du jetzt als Äquivalent zu deiner Lösung betrachtest, am ehesten wohl Server-Push. Die wesentlichen Vorteile, nämlich Ladezeiten und Netzwerklast durch einen progressiven Server zu reduzieren, kann ich bei dir allerdings nicht wiederfinden. Hier mal ein einfaches Beispiel wie Server-Push funktioniert:

                          Du gibst in der Adresszeile https://example.com/index.html ein, darauf reagiert der Server und schickt dir ein HTML-Dokument:

                          <!DOCTYPE html> <html> <head> <title>Hello World!</title> <link rel="stylesheet" href="style.css"> </head> <body> <h1>Hello World!</h1> </body> </html>

                          Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß, "PS: Du wirst gleich mit Sicherheit das Stylesheet style.css brauchen, hier hast du es schonmal". Der Browser denkt sich "Sehr zuvorkommend, die jungen Server von heute" dann fängt er an die HTML-Datei zu parsen, sieht dass er das Stylesheet tatsächlich gebrauchen kann, muss es aber nicht mehr anfragen, weil der Server es ihm ja schon zugesteckt hat. Ein wichtiger Punkt, das hat @Mitleser auch schon gesagt, ist dass das Stylesheet und das HTML-Dokument beide adressierbar bleiben und auch unabhängig voneinander gecacht werden können. Und Server-Push funktioniert auch schon beim ersten Seitenaufruf.

                          1. problematische Seite

                            Korrekt 😉 Im wesentlichen zeige ich das Prinzip HTTP/2 nur mit anderen Mitteln.

                            Wie @Mitleser schon sagte, gibt es nicht das eine Prinzip hinter HTTP/2, sondern eine Menge neuer Features. Mir ist nicht klar, welches Feature von HTTP/2 du jetzt als Äquivalent zu deiner Lösung betrachtest, am ehesten wohl Server-Push. Die wesentlichen Vorteile, nämlich Ladezeiten und Netzwerklast durch einen progressiven Server zu reduzieren, kann ich bei dir allerdings nicht wiederfinden.

                            Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann. Das hast Du doch verstanden wie Du an anderer Stelle schreibst!? Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm):

                            Rate formdata binary formdata 1.02/s -- -100% binary 213/s 20679% --

                            Im Übrigen ist auch JS ziemlich träge wenn ein FormData Objekt mit mehreren größeren Dateien erstellt werden muss. Wenn Du hier ein Upload > 1 MB mit mehreren großen Dateien aufstellst dauert es eine ganze Weile bis der Server antwortet.

                            Bei gleicher gesendeter Datenmenge antwortet der Server viel Schneller, wenn kein FormData Objekt erstellt wurde sondern die Daten aneinandergehängt wurden, der guckt sich eh nur den einen Header Content-Length an. Du siehst also, daß es nicht nur eine Frage des Offenhalten einer HTTP Connection ist sondern auch eine Frage der Art und Weise der Verpackung, also eine Frage des Serialize Algorithmus.

                            Und FormData ist so ziemlich die uneffizienteste Art, Daten zu serialisieren. Zumal sich mir der Sinn einer Boundary schon gar nicht erschließt, wenn ein Parser byte für byte arbeitet nämlich, ist eine Boundary nicht nur absolut überflüssig sondern auch noch hinderlich, weil sie von der rausgelesenen Teilsequenz wieder abgeschnitten werden muss.

                            HTTP/2 implementiert schließlich auch nur einen Kompromiß der hinsichtlich Abwärtskompatibilität getroffen werden muss. Kurzum: Es gibt effizientere Verfahren zum Übertragen mehrerer Dateien in einem Req/Response Zyklus und zwei davon zeigen meine DEMO's hier fürs Upload und hier fürs Download.

                            MfG

                            1. problematische Seite

                              Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann.

                              Alle im Web gebräuchlichen Formate sind streamingfähig, das ist also kein Alleinstellungsmerkmal deines Algorithmus'. Aber danach hatte ich auch garnicht gefragt, sondern nach dem HTTP/2-Feature, welches du eigenen Angaben zufolge "mit anderen Mitteln" zu erklären versuchtest.

                              Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm):

                              Nichts für Ungut, aber das sind nur Zahlen, was und wie du gebenchmarkt hast ist daraus nicht ersichtlich. Aber die Mühe musst du dir wegen mir auch nicht machen, Perl ist ohnehin nicht meine Welt.

                              1. problematische Seite

                                Wie bitte? Aber gerne noch einmal: Es ist ein gewaltiger Unterschied, ob ein Parser einen Binary erst im Hauptspeicher zerlegen muß oder ob man sofort nach dem Eintreffen des ersten Byte mit dem Lesen der Binary beginnen kann.

                                Alle im Web gebräuchlichen Formate sind streamingfähig, das ist also kein Alleinstellungsmerkmal deines Algorithmus'. Aber danach hatte ich auch garnicht gefragt, sondern nach dem HTTP/2-Feature, welches du eigenen Angaben zufolge "mit anderen Mitteln" zu erklären versuchtest.

                                Mehrere Dateien in einem Req/ResponseZyklus ist das Feature. Wars das jetzt!?

                                Den Benchmark hab ich hierzu auch geliefert, hier isser nochmal (Vgl. mit legacy CGI.pm):

                                Nichts für Ungut, aber das sind nur Zahlen, was und wie du gebenchmarkt hast ist daraus nicht ersichtlich.

                                Das habe ich hier sehr ausführlich erklärt.

                                Aber die Mühe musst du dir wegen mir auch nicht machen, Perl ist ohnehin nicht meine Welt.

                                Diesen Thread zu lesen und die Technik zu zu verstehen offensichtlich auch nicht. Im Übrigen hat das alles mit Perl gar nichts zu tun, außer daß ich den Benchmark und meine DEMOs mit Perl gemacht habe.

                                MfG

                          2. problematische Seite

                            Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

                            HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues. Du kannst das testen indem Du einen Low-Level-Client verwendest und die Request-Headers samt Bodies in ein einziges Socket schreibst. Beim letzten Request setzt Du dann Connection: CLose und kannst alle Responses aus ein und demselben Socket lesen.

                            Und nicht nur das, auch hierbei kannst Du die einzelnen Bodies unzerknittert voneinander trennen, egal ob sie chunked übertragen wurden oder am Stück: Sowohl chunked als auch am Stück werden die Längenangaben mitgeliefert, so daß jeder Body bytegenau wiederhergestellt werden kann.

                            Auf diese Art und Weise teste ich z.B. den Status meiner Domänen und kriege auf 350 HEAD Requests 350 Responses in wenigen Augenblicken, was ansonsten sehr viel länger dauern würde. Dieses Pipelining funktioniert sogar über Proxy. Mehr zum Parsen hier und da. MfG

                            1. problematische Seite

                              Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

                              HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues.

                              Doch, Server-Push erlaubt es dem Server nämlich auf eine Anfrage gleich mehrere Antworten zu schicken, nicht nur HTTP-Bodies, sondern ganze Anworten (Header und Bodies). Keep-Alive tut das nicht, das erlaubt nur die darunter liegende TCP-Verbindung wiederzuverwenden.

                              1. problematische Seite

                                Soweit, so HTTP/1. HTTP/2 schließt die Verbindung aber danach nicht, sondern sagt sinngemäß,

                                HTTP/1.1 schließt die Verbindung serverseitig auch nicht wenn der Client ein Connection: Keep-Alive gesendet hat. Insofern bietet da HTTP/2 nichts Neues.

                                Doch, Server-Push erlaubt es dem Server nämlich auf eine Anfrage gleich mehrere Antworten zu schicken, nicht nur HTTP-Bodies, sondern ganze Anworten (Header und Bodies). Keep-Alive tut das nicht, das erlaubt nur die darunter liegende TCP-Verbindung wiederzuverwenden.

                                Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

                                1. problematische Seite

                                  Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

                                  Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

                                  1. problematische Seite

                                    Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

                                    Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

                                    Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

                                    MfG

                                    1. problematische Seite

                                      Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

                                      Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

                                      Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

                                      Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

                                      1. problematische Seite

                                        Auch der Serverpusch war mit HTTP/1.1 schon möglich. MfG

                                        Das entspricht nicht der Wahrheit. Im HTTP/1.1 Standard taucht Server Push noch nicht auf, im HTTP/2 Standard erstmalig.

                                        Seit wann ist denn der Standard dafür maßgebend was möglich ist? Gerade hier in diesem Thread und auch auf meinen Seiten gehts ja gerade um Dinge denen Standards um Meilen hinterherhinken 😉

                                        Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

                                        Man kann mit Serverpush beliebige Inhalte senden. Die Frage ist nur, obs der Browser auch versteht und genau dafür ist HTTP/2 zuständig. MfG

                                        PS: http://search.cpan.org/dist/CGI/lib/CGI/Push.pm

                                        1. problematische Seite

                                          Yeah! Tschacka! Du bist ja ein Mann der Tat und Praxis. Also zeig uns doch bitte mal, wie Du analog dieses Beispiels via HTTP/1.1 einen Server Push realisieren würdest, um dem Client das CSS mitzuschicken.

                                          Man kann mit Serverpush beliebige Inhalte senden. Die Frage ist nur, obs der Browser auch versteht

                                          Du kannst auch z.B. via SSH ein passendes, eigenes Protokoll entwickeln. Solange Du dafür Sorge trägst, dass Deine Besucher sich den passenden Client besorgen (bzw. Du Apple davon überzeugst, dass analog in iOS zu implementieren), der damit umgehen kann, wird das funktionieren. Da stellt sich dann nur irgendwie die Frage der Relevanz einer solchen Lösung ;-) Aber glücklicherweise haben wir da ja schon was:

                                          und genau dafür ist HTTP/2 zuständig

                                          You got it.

                                          Wobei "genau dafür" erneut unpräzise ist. HTTP/2 definiert mehrere Erweiterungen, das ist nur eine. Und ja: wenn Du deine eigenen Server und Clients schreibst, dann wirst Du jede einzelne Erweiterung von HTTP/2 abbilden können. Nur ob Du es schaffst, die auch unter das Volk zu bringen, ist irgendwie fraglich, oder? Schonn kommt da irgendwie wieder die Frage nach der Relevanz auf...