Firefox 300 s hardcoded Timeout

d4f said:
Gerne kann ich eine auf deinen Fall passende Lösung für einen angemessenen Stundenlohn entwerfen und implementieren.
Click to expand...

PHP: 
<?php
sleep(301);
echo "fertig";
?>

Dieses Script soll mit Firefox ohne Änderung der genannten Variable in Firefox und ohne Änderung am Phpcode laufen und "fertig" ausgeben.

Klar bitte ein Angebot an webmaster@serverman.de .

Du hast es einfach nicht verstanden was hier passiert, genauso wie ich es nicht verstanden hatte bis zu dem Punkt wo ich auf den Bug aufmerksam wurde. Die Lösung steht hier für alle nachvollziehbar sichtbar.

Auf dein Angebot freue ich mich.

Solche Leute wie du sind mir die Liebsten :-)
 
Last edited by a moderator:
s24! said:
Sach ma, wie talkst du eigentlich mit Daniel? :eek:
Click to expand...

Sorry, ich dreh durch. Der hats voll raus aber glaubt mir einfach nicht. Man kann es serverseitig nicht beeinflussen! Und faselt dann noch was das ich verifizierter Anbieter bin mit sonnem Problem... Ej geht's noch? :eek:

Wer mich kennt der weiß das ich etwas versierter bin als der Durchschnittsprovider Business Betreiber. :p
 
Um mal wieder zum eigentlichen Thema zurück zu kommen: Ich finde diese Änderung gut! Vielleicht kapieren die Programmierer es jetzt endlich mal, dass eine Minuten oder gar stundenlang arbeitende HTTP-Verbindung ohne echten Datenaustausch sinnlos ist. Weil an Proxy's und andere zwischengeschaltete Problemstellen (die solche langen Timeouts logischerweise nicht unterstützen können), dachte in der Vergangenheit selten jemand.

@Import: Das kann man doch wunderbar auf Zwischenschritte aufteilen. Oder gleich mit Ajax usw. :rolleyes:


MfG Christian
 
Keine Frage, die Sinnhaftigkeit ist sicher bestimmt -aus irgendeinem Blickwinkel- gegeben, nur ist die Realität leider eine andere.

- verschlüsselte Scripte
- keiner weiß das
- alte Scripte die laufen müssen
- allein schon die Position in der man ist (Hoster? Entwickler? Kunde?)
- wer soll die Anpassung der Kundenscripte machen?
- Verständnis auf Seite der Kunden? ("Vorher lief doch alles mit dem Script und jetzt wollen Sie Geld damit das bei Ihnen läuft? Ach Firefox, das sagen Sie doch nur weil Sie Geld wollen!")
- erklär das mal Lieschen Müller.

Verstehste? Das ist alles nicht sooo einfach.

Klar sind die Scripte kacke die sowas machen, keine Frage da bin ich im gleichen Boot.

Ich befürchte keiner wirklich keiner der versierten User hier hat diese Tatsache gewusst bevor ich das Thema hier reingeworfen habe..
 
Das verstehe ich durchaus. Aber manchmal müssen drastische Schritte getroffen werden, wenn man langfristig gesehen Änderungen herbeiführen will. Das ist nicht nur bei Mozilla so. Und das ist auch nicht 100% zu befürworten, aber im Endeffekt ist man Jahre oder Jahrzehnte später dankbar für diesen Schritt.

Ich wusste es bis heute auch nicht und es sollte vielleicht besser kommuniziert werden. Aber sei mal ehrlich: 99% der Browsernutzer werden niemals mit diesem Timeout in Berührung kommen – die wissen nicht einmal, dass es soetwas gibt oder wofür das gut sein soll ;)


MfG Christian
 
Bei mir bin ich drauf gekommen weil ein Kunde halt frisch zu mir gezogen ist und es auf dem alten Server, im März, mit Firefox 28 einwandfrei ging.

Der bekommt einfach alle paar Monate von einem Lieferanten einen Dump, für welchen er dann ein CMS Module hat bauen lassen mit glaube 2k Zeilen was die Preise abgleicht aus dem 30 Mb Dump und die Änderungen am Schluß optional in die DB einfügt... Wenn man denn dann auf die letzte Seite kommt auf der der Button ist...

Danke dir jedenfalls das du das Problem wenigstens vollständig verstehst und genau das sagst was richtig ist.
 
Last edited by a moderator:
DjTom-i said:
Jeder der eine max_execution_time >= 301 Sekunden braucht hat jetzt ein Problem.
Click to expand...

Allerdings. Derjenige sollte sein PHP-Script mal überarbeiten oder besser node.js nutzen.

DjTom-i said:
Bei mir bin ich drauf gekommen weil ein Kunde halt frisch zu mir gezogen ist und es auf dem alten Server, im März, mit Firefox 28 einwandfrei ging.

Der bekommt einfach alle paar Monate von einem Lieferanten einen Dump, für welchen er dann ein CMS Module hat bauen lassen mit glaube 2k Zeilen was die Preise abgleicht aus dem 30 Mb Dump und die Änderungen am Schluß optional in die DB einfügt... Wenn man denn dann auf die letzte Seite kommt auf der der Button ist...

Danke dir jedenfalls das du das Problem wenigstens vollständig verstehst und genau das sagst was richtig ist.
Click to expand...

Er sollte denjenigen, der das CMS-Modul entwickelt hat um Verbesserung des Codes bitten.

Beste Beispiel ist doch der mysqldumper. Da funktioniert es doch auch....irgendwie. Soweit ich weiß, teilt er sich das Backup in kleinere Häppchen auf. Dann bekommt er die gleiche Seite mit dem Fortschritt angezeigt. Eigentlich recht einfach gelöst.
 
Last edited by a moderator:
Dead_Eye das was du schreibst ist alles richtig, keine Frage. Der alte dev ist nicht mehr greifbar.. Um "den" einen Kunden geht es ja auch nicht wirklich.. Auch nicht um das eine Script was aa ist...

Die von dir genannten Lösungsvorschläge führen leider nicht bei allen Usern zu einer Lösung.

Und wie erwähnt in dem Fall wird nicht das geringste auf dem Server gelogged :-(
 
Also alle relevanten großen Seiten funktionieren bei mir unter Windows mit dem FF.

Letztendlich sollen sich die User an Mozilla wenden oder den Browser wechseln.
Aber wie gesagt, eine Website, die mehr als 301 Sekunden zum Laden benötigt, ist "kaputt". Ich kann mich nicht erinnern, wann ich das letzte Mal so lange auf etwas gewartet habe. Meist kam dann schon vor den 301 Sekunden ein Timeout vom Nginx.
 
Das bringt aber nichts was du sagst. Die User kacken auf nur einen Euro extra den Sie ausgeben müssen nur weil sich etwas "geändert" hat.

Nginx kannste aber anpassen serverseitig und die Laufzeit somit verlängern. Da is nix mit anpassen serverseitig wenn genau "das" Script laufen muß und es keine Alternativen oder Optionen gibt.
 
Man kann es serverseitig nicht beeinflussen!
Click to expand...
Doch kann man, wie ich dir per PN mit einer Erklärung bereits geschickt hatte. Dass ich den Link zum gehosteten Beispiel darin vergessen hatte ist etwas peinlich aber keineswegs einen Grund ausfallend zu werden.

Verständnis auf Seite der Kunden?
Click to expand...
Erfahrungsgemäß (~10'000 Kunden) respektieren und glauben die Kunden einer objektiven, detaillierten und verständlichen Erklärung des Anbieters über die technische Begründung. Das Schlagwort ist hier aber "objektiv", ich hoffe doch stark dass deine Kommunikation gegenüber Kunden deutlich polierter ist als das was hier im Thread zutage kommt.

und genau das sagst was richtig ist.
Click to expand...
Falls du damit suggerieren willst dass ich was Falsches in Anbetracht der bekannten Tatsachen gesagt habe - bitte her damit.
 
Na soweit alles easy. Dein Beispiel aus der PM funktioniert in deiner Konfig. Somit hast du mich schon mal überzeugt das da was geht.

Ich bin mir nur nicht sicher ob das Ziel klar ist: Transparent für den Kunden dieses Problem wegbügeln sodaß kein Script geändert werden muß. Das mit einem normalen Plesk Server mit Apache2. Oder mit einem Confixx Server mit Apache2.
 
Ich bin mir nur nicht sicher ob das Ziel klar ist: Transparent für den Kunden dieses Problem wegbügeln sodaß kein Script geändert werden muß.
Click to expand...
Jein. Dazu muss jedoch ein Proxy-Server, konkreter ein Nginx mit den Erweiteren http_proxy und LUA (empfohlen: Lua-JIT) dazwischengeschaltet werden. Das ist sowohl für den Kunden als auch für die Serverumgebung transparent möglich dank iptables und Apache mod_rpaf2.
Ich setze (recht erfolgreich) ein Nginx zur Optimierung / Angriffsblockierung und anderen nützlichen Features vor 0815 CPanel so ein, es ist also durchaus produktiv einsetzbar.

Volltransparent ist es jedoch nur für den Benutzer, jedoch nicht deinen Kunden welcher entsprechende Pfade melden muss damit Nginx sie entsprechend behandelt. Der damit verbundene Aufwand ist allerdings zumindest für den Kunden "fire&forget" und somit eher mäßig. Man könnte es vermutlich auch autmatisch bei einer Skriptlaufzeit > x Sekunden aktivieren lassen aber damit verkompliziert man die Sache recht stark.
 
Last edited by a moderator:
Siehst du und sowas muß ich dann für Rootserver, Vserver, etc mit allen möglichen Paneln (Plesk, Confixx, i-mscp, cpanel) entwickeln und "allen" bereitstellen. Das auch noch als Autoinstallation für diverse Provider die ich bediene damit sowas auch blos nicht vorkommen kann bei den Kunden. Das ist ja ein Skandal wenn ein 10 Jahre altes Script plötzlich nicht mehr acht Minuten laufen darf auf dem neuen Server... Ein Scheiß Server ist das...

Hat nicht mal einer nen Lolli für mich???

Das ist ja jetzt ein bekanntes Problem und vom Hoster zu lösen...

d4f Respekt für den Workaround. U Rock. Wenn du mal nen Job suchst... Vermittel dich gerne..

Ich denke aber eher die Lösung mit dem about:config ist die sinnvollere zunächst! Oder?
 
Wenn du mal nen Job suchst... Vermittel dich gerne..
Click to expand...
Hehe danke. Ich werde aber bereits belagert wenn ich denn (*hust* endlich) mit dem Studium fertig sei. Momentan ist eher die Zeit als das Angebot mein Problem :D

Ich denke aber eher die Lösung mit dem about:config ist die sinnvollere zunächst! Oder?
Click to expand...
Ich denke dass die betroffenen Kunden wohl an einer Hand abzählbar sind, falls es überhaupt generell mehr als Einer ist. In diesem Sinne wäre es sogar gegen Entgeld machbar einfach eine portable Version des Browsers mit entsprechender Voreinstellung an zu bieten. Alternativ; dem Kunden die Konkurrenz schmackhaft machen. Über .htaccess liesse sich ja auch für den Import mit etwas Spielerei eine Seite anzeigen "nur mit Internet Explorer kompatibel". Back to the basics...

Hier zur Vollständigkeit mein Proof-of-concept Nginx/Lua Code. Er fabriziert einen 200 Response Code Header und sendet ihn aus bevor Upstream geöffnet wird wodurch Firefox' first_byte_timeout besänftigt ist. Der between_byte_timeout ist deutlich höher und hier (noch) kein Problem. Beim Lesen wird vermutlich offensichtlich das bis zu einer gangbaren Lösung für den Regelbetrieb noch ein Stück Arbeit vor dem Implementierer liegt.

Code: 
server {
	listen *:3456;

	location /test/sleep.php {
		content_by_lua '
				-- Terrible assumption, only for proof of concept 
				ngx.header["Content-Type"] = "text/html"
				
				-- Prematurely send a fabricated header for first_byte_timeout bypass
				local ok,err = ngx.send_headers()
				if not ok then
						ngx.log(ngx.ERR,"Could not send headers!")
						ngx.log(ngx.ERR,err)
				end
				ngx.flush()

				-- Get and send response
				-- Assumption for PoC: response body is rather small
				-- Assumption for PoC: request is GET, has no body, has no parameters, ...
				local response = ngx.location.capture("/.internal/test/sleep.php")
				ngx.say(response.body)
		';
	}

	location /.internal/ {
			-- Uhm.... yeah. PoC!
			rewrite_by_lua '
					ngx.req.set_uri("/test/sleep.php", false)
			';
			internal;
			proxy_set_header Host "XXXXX.tld";
			proxy_pass http://XXXXX.tld;
	}

}
 
Last edited by a moderator:
Worauf wir uns einigen können ist sicher das es eine Lösung gibt.

Diese aber nicht mit "Einstellungen" wie ich sie klassich meinte mit Parametern die man verändert per Vhost, per php.ini oder per Paramteren in der Datei oder htaccess beeinflussbar ist.

Proxy davor hängen und den Header faken (hier nicht negativ gemeint, es erfüllt ja seinen Zweck zunächst) wäre die Lösung.

Ich befürchte soweit wie du das Problem mit durchdacht hast stimmst du mir auch vermutlich zu das eine derartige Änderung seitens Mozilla zu Komplikationen führt?

Kanns nur wiederholen: Sehr pragamtisch gelöst in deinem Setup. Danke für den Ansatz.
 
You must log in or register to reply here.
Back
Top