FHEMWEB/HTTPSRV Bug: Parallele Anfragen liefern vertauschte Antworten

[Wolfspirit]

Hi,

Ich weiß leider nicht wo ich mein Problem am besten Posten sollte.

Ich hab nun TabletUI installiert doch das Problem betrifft nicht direkt TabletUI sondern das Modul HTTPSRV bzw. vermutlich FHEMWEB direkt.

Das Problem:
Ich hab immer wieder Fehler beim Laden von Dateien die per HTTPSRV (gleichzeitig) ausgeliefert werden.
Es werden ab und zu falsche bzw. garkeine Dateien ausgeliefert (im Chrome 49).
z.B. hat TabletUI die Datei jquery.toast.min.js im "/js/" Ordner liegen.
Beim Laden der Seite wirft sie mir ab und zu eine Fehlermeldung "$.toast is not a function" und schaue ich anschließend nach welche Datei über jquery.toast.min.js ausgeliefert wurde ist es eine ganz andere als angefragt.

Anbei ein Screenshot von 2 Requests.
Der erste hat nicht funktioniert und gibt in der toast Datei das eigentliche Script von fhem-tablet-ui-2.0_beta zurück (In fhem-tablet-ui-2.0_beta selbst wird angeblich ein leerer Response zurück gegeben)

Ich denke, dass bei der Verarbeitung im HTTPSRV bzw. FHEMWEB  ein Bug steckt (Leider weiß ich nicht wo ich Bugreports am besten posten sollte)
Dieser Bug vertauscht hin und wieder die Antworten (häufiger mit HTTPS, aber auch ohne HTTPS).
Das ganze konnte ich auch mit Fiddler (HTTP Proxy) nachstellen!
Angehängt ist auch der Fiddler Screenshot.
Wie man sehen kann wurde in diesem Fall das ganze jquery über die datei jquery.gridster.min.js geladen und jquery.min.js selbst hatte 0 Bytes übertragen.
jquery.gridster.min.js hat natürlich daraufhin gefehlt!

Sobald ich in meinem Web folgendes mache scheint es Problemlos zu funktionieren, da hier nicht mehrere Files parallel über einen Kanal gesendet werden:
attr WEB closeConn 1

Könntet ihr das bitte mal überprüfen?
Ich denke, dass das Problem auch das normale FHEM Frontend betrifft.

[rudolfkoenig]

Ich weiß leider nicht wo ich mein Problem am besten Posten sollte.

Eigentlich einfach, steht oben bei den Anfaengerfragen.

Könntet ihr das bitte mal überprüfen?

Nicht ohne ein nachstellbares Beispiel. Dieses Problem hoere ich zum erstenmal, es kommt also nicht sehr oft vor. FHEM ist Single-Threaded, deswegen fehlt mir die Fantasie, wie FHEMWEB zwei Anfragen vertauschen sollte.
Evtl. ist es ein HTTPSRV Problem, dann ist es aber nicht meine Baustelle.

[Wolfspirit]

Danke für deine Antwort.

Ich konnte das Problem nun weiter einkreisen und hab vermutlich den Fehler gefunden.

FHEM Tablet UI liefert im Default index.html eine user.css Datei mit die nicht vorhanden ist.
Sobald diese Datei geladen wird und einen 404 produziert scheint FHEMWEB Probleme zu bereiten.

Das ganze lässt sich relativ einfach nachstellen indem man eine Seite hat die länger läd (mehrere Plots z.B.) und während sie läd in einem anderen Tab z.B. das hier aufruft und vielleicht ein paar mal aktualisiert:
http://fhem:8083/fhem/pgm2/bla.css
Dabei geschehen "ungewöhnliche" Dinge. Mal Fehlen Icons, mal wird eine SVG_showLog heruntergeladen.

Ich bin noch nicht ganz durchgestiegen wie FHEMWEB die Header innerhalb eines TCP Streams handled, aber mir scheint das dort ein Fehler passiert.

Ich habe auch eine Lösung gefunden:

Es geht um die Zeile 1687 in der 01_FHEMWEB.pm:

Code Auswählen Erweitern


if(!open(FH, $path)) {
    Log3 $FW_wname, 4, "FHEMWEB $FW_wname $path: $!";
    TcpServer_WriteBlocking($FW_chash,
        "HTTP/1.1 404 Not Found\r\n".
        "Content-Length:0\r\n\r\n");
    FW_closeConn($FW_chash);
    return 0;
  }


Sobald ich hier anstelle von return 0 ein return -1 übergebe scheint es zu funktionieren.
Wenn hier ein 0 übergeben wird durchläuft er ja auch Zeile 472 (addToWritebuffer... (200 OK))

Sehe ich das richtig, dass er bei 0 also nicht einfach abschließt sondern hinterher noch ein 200 OK schickt?
Wobei answerCall FW_RET ja eigentlich auf leer setzt, daher kann ich mir noch nicht ganz erklären warum er hier "falsche" Daten ausliefert. (Siehe EDIT)

Mit return -1 gibt es jedenfalls keine Probleme mehr.
Das Problem tritt nicht oft auf, da es im FHEM Frontend ja keine fehlenden Dateien gibt und die user.css entweder entfernt wird oder von usern angelegt und mit Daten gefüllt wird.

Doch scheint das Problem schon bei mehreren aufgetreten zu sein nur der Fehler wurde bis jetzt noch nicht gefunden:
https://goo.gl/eK4uYy
Eine Fehlende CSS Datei ist zwar unschön aber dennoch valide


P.S.: Sorry für den Post im falschen Forum. Wenn möglich bitte einfach verschieben. Wäre vermutlich Frontends richtiger gewesen?!

EDIT: Ich hab nochmal überlegt wie die "vertauschten" Daten zustande kommen könnten und bin nun zu diesem Ergebnis gekommen:

> GET /test.js
< 200 OK (inhalt test.js)
> GET /data.js
< 404 Not Found
(Schreibt aber noch ein  200 OK Empty in den Stream)
> GET /test2.js
< 200 OK Empty (von vorher noch!)
(Schreibt aber noch ein 200 OK (inhalt von test2.js) in den Stream)
> GET /something.else
< 200 OK (inhalt von test2.js!)

Es ist also vermutlich ab dem 404 alles um eine Antwort versetzt. Daher kam auch die leere Antwort.

[rudolfkoenig]

Die festgestellte Ursache ist meiner Ansicht nach richtig, habe die vorgeschlagene Aenderung eingecheckt.