Base64-Kodierung wird nicht immer benötigt, ihre derzeitige Anwendung entpackt Inhalte ggfs zu früh

[denkspuren]

Um beliebige Textinhalte kompatibel mit den Anforderungen an Server Sent Events zu halten, werden die Daten zu einem SSE derzeit per Base64 serverseitig kodiert und clientseitig im Browser dekodiert. Grund ist, dass SSEs grundsätzlich als Text mit einem doppelten \n (Zeilenumbruch) am Ende verschickt werden. Tauchen im Text selber doppelte Zeilenumbrüche auf, ist das nicht vom eigentlichen Textende zu unterscheiden und erzeugt Probleme.

Die derzeitige Implementierung selber ist nicht ganz problemfrei:

• Wenn alle SSEs eine Base64-Kodierung erfahren, erhöht das den Payload um rund ein Drittel und kostet beidseitig Rechenzeit zur beständigen Kodierung und Dekodierung. Das ist z.B. für die vielen SSEs bei Turtle-Grafiken ein Overhead ohne jegliche Notwendigkeit.

• Im LVP setzt sich jedes SSE aus einer Aktion und den mitgelieferten Daten zusammen. Im Fall etwa der Aktion SCRIPT werden die Daten dekodiert und in den Rumpf eines öffnenden und schließenden script-Tags eingesetzt. Dabei könnte z.B. ein unbalancierter enkodierter HTML-Text die Script-Struktur zerstören. Der sollte zunächst enkodiert bleiben und erst im Gebrauchsfall dekodiert werden.