ab 5.2 fortschrittsanzeige möglich?

[Roger]

moin!

ich hab gehört, dass es in 5.2 (rc *) endlich die möglichkeit der dateigrößenabfrage bei uploads gibt, was eine fortschrittsanzeige ermöglicht. ich warte ja schon seit '45 darauf :)
wäre echt cool, wenn das wirklich jetzt umgesetzt wird. (hab keine lust auf die patches da draußen).

hat schonmal jemand davon gehört/etwas damit gemacht?

gruß.
roger.

[dedlfix]

echo $begrüßung;

ich hab gehört, dass es in 5.2 (rc *) endlich die möglichkeit der dateigrößenabfrage bei uploads gibt, was eine fortschrittsanzeige ermöglicht.
hat schonmal jemand davon gehört/etwas damit gemacht?

Du kannst das in PHPs TODO-Liste nachlesen. Ich finde das nur unter PHP 6.0.0, glaube mich aber zu erinnern, das auch schon für 5.2 angekündigt gehört zu haben.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

glaube mich aber zu erinnern, das [Upload-Fortschrittsanzeige] auch schon für 5.2 angekündigt gehört zu haben.

In der Heise-Newsticker-Meldung war darüber nichts zu lesen, aber in einem Kommentar dazu.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

ich hab gehört, dass es in 5.2 (rc *) endlich die möglichkeit der dateigrößenabfrage bei uploads gibt, was eine fortschrittsanzeige ermöglicht. ich warte ja schon seit '45 darauf :)

Das Problem besteht aber immer noch, dass du die Fortschrittsinformation irgendwie an den Browser senden mußt.

Und in dem gleichen Fenster, in dem das Formular abgeschickt wurde, geht das eben nicht. Du brauchst in jedem Fall ein zweites Fenster/Frame/Iframe, und zwingend auch ein zweites Skript, welches die Information an dieses Fenster liefert. Und damit das zweite vom ersten Skript was mitkriegt, auch noch einen Verbindungsmechanismus, z.B. Sessions.

- Sven Rautenberg

[Roger]

moin!

Das Problem besteht aber immer noch, dass du die Fortschrittsinformation irgendwie an den Browser senden mußt.

in zeiten von super-blinki-ajax sollte das ja kein problem mehr sein.
die umsetzung ist mir auch erst mal zweitrangig. hauptsache ist, dass es wohl demnächst wirklich geht. *froi*

gruß.
roger.

[wahsaga]

hi,

Das Problem besteht aber immer noch, dass du die Fortschrittsinformation irgendwie an den Browser senden mußt.

in zeiten von super-blinki-ajax sollte das ja kein problem mehr sein.

Auch da könnte es noch Probleme geben - dein AJAX-Request, der den aktuellen Status in Erfahrung bringen soll, muss sich ja noch irgendwie am aktuell laufenden Upload-Request "vorbeimogeln".
Und je nachdem, wie viele Verbindungen zum Server aktuell schon bestehen bzw. zugelassen sind (client- und serverseitig), und wie die Leitung durch den Upload ausgelastet ist, dürften auch da vermutlich noch Verzögerungen zu erwarten sein.

gruß,
wahsaga

[Roger]

moin!

Und je nachdem, wie viele Verbindungen zum Server aktuell schon bestehen bzw. zugelassen sind (client- und serverseitig), und wie die Leitung durch den Upload ausgelastet ist, dürften auch da vermutlich noch Verzögerungen zu erwarten sein.

naja, ich erwarte ja nicht das superpräziese verhalten. aber es hilft schonmal immens, wenn man bei einem 10mb-upload ungefähr weiß wie lange man noch braucht.
welche technik dazu verwendet wird, ist mir in erster linie wie gesagt wurscht.

gruß.
roger.

[Sven Rautenberg]

Moin!

naja, ich erwarte ja nicht das superpräziese verhalten. aber es hilft schonmal immens, wenn man bei einem 10mb-upload ungefähr weiß wie lange man noch braucht.
welche technik dazu verwendet wird, ist mir in erster linie wie gesagt wurscht.

Ich sehe da eigentlich die Browser in der Pflicht.

Die sind jetzt dafür verantwortlich, einen Fortschrittsbalken beim Seitenladen anzuzeigen (manche machen das ganz ordentlich, andere wie der IE faken ihn auch nur und zeigen "Fortschritt", wo keiner ist).

Also sind sie auch verantwortlich für einen Upload-Balken, wenn Formulare mit großen Mengen an Daten gesendet werden.

Dummerweise hat noch kein Browser derzeit so etwas integriert - aber es ist seine Aufgabe, das anzuzeigen, denn nur der Browser weiß exakt, wieviele Bytes zu senden sind, und wieviele er schon gesendet hat.

Alle Versuche, serverseitig Ersatz zu schaffen, sind technisch zu aufwendig - und würden auch überflüssig, sobald Browser den Upload-Fortschritt von selbst anzeigen.

Diese Idee sollte also mal jemand den Browserprogrammierern stecken.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

Das Problem besteht aber immer noch, dass du die Fortschrittsinformation irgendwie an den Browser senden mußt.

Und in dem gleichen Fenster, in dem das Formular abgeschickt wurde, geht das eben nicht. Du brauchst in jedem Fall ein zweites Fenster/Frame/Iframe, und zwingend auch ein zweites Skript, welches die Information an dieses Fenster liefert. Und damit das zweite vom ersten Skript was mitkriegt, auch noch einen Verbindungsmechanismus, z.B. Sessions.

Ich denke, hier irrst du. Ein Client hat einen Haufen HTML im Speicher rumliefen, den er gerade hübsch gerendert anzeigt. Darin befindet sich ein Formular mit einem File-Upload. Beim Abschicken werden die Formulardaten inklusive Datei mit einem POST-Request auf Ressource x.php zum Server gesendet. Nun kommt es drauf an, wann PHP in Erscheinung tritt. Werden zuerst alle Daten empfangen und dann erst dem PHP übergeben ist die Fortschrittsanzeige mit PHP nicht zu realisieren. Bekommt PHP bereits von Anfang an Wind vom Request, weiß es, welches Script aufzurufen ist, und kann schon auf irgendeine Weise tätig werden. Loslaufen lassen kann es das Script noch nicht, da ja noch nicht alle Daten ($_POST und $FILES) zur Verfügung stehen. In diesem Zustand müssten sich auch schon Antwortdaten auf den Request zum Client übertragen lassen. Der Browser müsste ungeachtet des noch laufenden Uploads schon auf einen neuen HTML-Haufen warten. (Irgendwie müssen ja die bisherigen Imlementierungen eines Fortschrittsbalkens auf diesem Prinzip basieren.)

Deinen komplizierten Gedankengang mit dem zweiten Fenster und zwei Scripts kann ich irgendwie nicht nachvollziehen.

Meine Recherchen bezüglich des Themas in den Tiefen des PHP-Quellcodes förderten zu Tage:
In der Datei /main/rfc1876.c wurde vor reichlich 3 Wochen an verschiedenen Stellen Code eingefügt, der zum Thema passt (auch der CVS-Kommentar ("Added RFC1867 fileupload processing hook.") passt dazu. Wenn ein Callback namens "php_rfc1867_callback" existiert, wird dieser mehrfach mit diversen Daten des Uploads benachrichtigt. Es gelang mir nicht, das andere Ende dieses Callbacks zu finden. Außerhalb der Datei kommt die Zeichenfolge "php_rfc1867_callback" nicht vor. Innerhalb ist auch keine PHP-Funktionsdeklaration zu finden, die normalerweise mit (dem Makro?) PHP_FUNCTION eingeleitet wird. Der einzige interessante Anknüpfungspunkt scheint Zeile 38 zu sein, deren Sinn ich aber nicht richtig verstehe, außer dass es sich wohl um eine Funktionssignatur handeln muss.

Ich befürchte, dass man seine Fortschrittsbalkenvorfreude noch länger als bis zum Erscheinen von PHP 5.2 dämpfen muss.

echo "$verabschiedung $name";

[Sven Rautenberg]

Moin!

Deinen komplizierten Gedankengang mit dem zweiten Fenster und zwei Scripts kann ich irgendwie nicht nachvollziehen.

Ist aber ganz simpel, wenn man weiß, wie HTTP funktioniert: Erst der komplette Request, dann der Response.

Der Browser schickt die Dateien weg, und erst wenn er damit fertig ist, erhält er vom Server die Antwort. Das bedeutet, dass innerhalb dieser Antwort keinerlei Fortschrittsanzeige generiert werden kann, weil die ja erst nach Abschluß des Uploads erscheinen würde - was dem Prinzip einer Fortschrittsanzeige widersprechen würde.

In der Datei /main/rfc1876.c wurde vor reichlich 3 Wochen an verschiedenen Stellen Code eingefügt, der zum Thema passt (auch der CVS-Kommentar ("Added RFC1867 fileupload processing hook.")

Zumal RFC 1867 nichts in in Richtung "Fortschrittsbalken" definiert, sondern die RFC ist, die in Formularen den <input type="file"> eingeführt hat. Server- oder clientseitige Behandlung von Uploads ist nicht wirklich Thema der RFC.

passt dazu. Wenn ein Callback namens "php_rfc1867_callback" existiert, wird

dieser mehrfach mit diversen Daten des Uploads benachrichtigt.

Bleibt die Frage: Wann passiert das, und welchen Zustand hat das oder haben die Skripte auf dem Server dann?

Ich befürchte, dass man seine Fortschrittsbalkenvorfreude noch länger als bis zum Erscheinen von PHP 5.2 dämpfen muss.

Wie erwähnt: Ich halte es für ziemlichen Overkill, für so eine grundlegende Funktion wie dem Formularupload ein riesiges, aber zwingend notwendiges Konstrukt aus Fenstern/Frames, höchstwahrscheinlich Javascript und AJAX, Session-Management und häufigen Reloads bzw. HTTP-Streaming aufzubauen, wenn die einfachste Lösung doch ist, dass einfach der Browser einen besseren Fortschrittsbalken kriegen kann, wodurch auf einen Schlag alle Upload-Formulare profitieren würden, und nicht nur die, die aufgrund ihrer Technik auch grandios scheitern können.

- Sven Rautenberg

[dedlfix]

echo $begrüßung;

Ist aber ganz simpel, wenn man weiß, wie HTTP funktioniert: Erst der komplette Request, dann der Response.

Und es ist komplett ausgeschlossen, dass bereits während des Requests Response-Daten zum Client gelangen?

passt dazu. Wenn ein Callback namens "php_rfc1867_callback" existiert, wird dieser mehrfach mit diversen Daten des Uploads benachrichtigt.
Bleibt die Frage: Wann passiert das, und welchen Zustand hat das oder haben die Skripte auf dem Server dann?

Es gibt zumindest die Ereignisse:
MULTIPART_EVENT_START
MULTIPART_EVENT_FORMDATA
MULTIPART_EVENT_FILE_START
MULTIPART_EVENT_FILE_DATA
MULTIPART_EVENT_FILE_END
MULTIPART_EVENT_END

Für den Rest bleibt wohl nur abzuwarten oder in einem Mailinglistenarchiv Diskussionen zum Thema zu entdecken.

echo "$verabschiedung $name";

[Alexander Brock]

Hallo Forum,

Und es ist komplett ausgeschlossen, dass bereits während des Requests Response-Daten zum Client gelangen?

Ich halte es für absolut blödsinnig, während des Uploads versuchen schon mal eine Anwort vom Server zu erhalten, ich habe schon HTTP-Clients geschrieben und darauf wäre ich ganz sicher nicht gekommen.

In der RFC kann ich auch nichts Gegenteiliges finden:

"The HTTP protocol is a request/response protocol. A client sends a request to the server [...] The server responds [...]" (HTTP/1.1: Introduction 1.4 Overall Operation)

Wenn der Server während des Uploads Daten an den Client schicken könnte würde da meines Erachtens stehen "The HTTP protocol is a streaming protocol [...]".

Außerdem ist ein Fortschrittsbalken tausendmal einfacher zu implementieren.

Gruß
Alexander Brock

[dedlfix]

echo $begrüßung;

Und es ist komplett ausgeschlossen, dass bereits während des Requests Response-Daten zum Client gelangen?

Ich halte es für absolut blödsinnig, während des Uploads versuchen schon mal eine Anwort vom Server zu erhalten, ich habe schon HTTP-Clients geschrieben und darauf wäre ich ganz sicher nicht gekommen.

In der RFC kann ich auch nichts Gegenteiliges finden:

Ich würde es komisch/bedenklich finden, wenn dem Server nicht erlaubt wäre, in einen Request mit jeder Menge Daten im Anhang dazwischenzufunken, um dem Client beispielsweise mitzuteilen, dass der Anhang völlig uninteressant ist, weil eh keine Zugriffserlaubnis auf die angeforderte Ressource besteht.

Und in der Tat lese ich in Abschnitt 8.2.2 Monitoring Connections for Error Status Messages:

An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD    immediately cease transmitting the body.

Damit wäre schon mal im Fehlerfall eine Response möglich während der Request noch läuft.

Das folgende Kapitel beschäftigt sich mit dem Verhalten bei aufgeteilten Requests (100-Continue) Auch da findet eine Kommunikation quasi während des laufenden Requests statt, wenn dabei auch bloß Statusmeldungen und keine für den serverseitigen Fortschrittsbalken nötigen Nutzdaten übertragen werden können.

Der Rest der RFC geht, so wie es mir scheint, nicht weiter auf den zeitlichen Ablauf von Request und Response ein. Ich kann da kein Verbot der vorzeitigen Antwort sehen.

"The HTTP protocol is a request/response protocol. A client sends a request to the server [...] The server responds [...]" (HTTP/1.1: Introduction 1.4 Overall Operation)

Wenn der Server während des Uploads Daten an den Client schicken könnte würde da meines Erachtens stehen "The HTTP protocol is a streaming protocol [...]".

Da steht aber nichts vom zeitlichen Ablauf der ganzen Geschichte. Aus der ASCII-Grafik kann ich nichts Gescheites entnehmen.

Außerdem ist ein Fortschrittsbalken tausendmal einfacher zu implementieren.

Wie stellst du dir das Verhalten des Browsers vor, wenn ein Proxy zwischengeschaltet ist? Der Request landet samt Body beim Proxy. Der Fortschrittsbalken flog nur so vorbei, weil der Proxy im schnellen Intranet steht. Was soll nun der Browser in der Zwischenzeit machen, solange der Request über die dünnere Außenanbindung vom Proxy zum Webserver übertragen wird? Wie soll der User reagieren, wenn ihm signalisiert wird, "Request ist erledigt" aber der Server mit der Antwort auf sich warten lässt?

echo "$verabschiedung $name";

[wahsaga]

hi,

Bekommt PHP bereits von Anfang an Wind vom Request, weiß es, welches Script aufzurufen ist, und kann schon auf irgendeine Weise tätig werden. Loslaufen lassen kann es das Script noch nicht, da ja noch nicht alle Daten ($_POST und $FILES) zur Verfügung stehen. In diesem Zustand müssten sich auch schon Antwortdaten auf den Request zum Client übertragen lassen. Der Browser müsste ungeachtet des noch laufenden Uploads schon auf einen neuen HTML-Haufen warten.

Und wie ersetzt du dann den bereits losgeschickten "Balken" nach dem Ende des Uploads bspw. durch eine Bestätigungsseite?
Einem Browser, der bereits ein HTML-Dokument empfangen hat, rein serverseitig ein neues HTML-Dokument unterzuschieben, dürfte schwierig werden. (Und mit irgendwelchem flush-Gebastel, womit wir nach einem bisher nur teilweise und unvollständig ausgelieferten Dokument dann noch einen "Rest" nachschieben, wollen wir ja wohl nicht anfangen. Zumal ja gar nicht gesagt wäre, dass der Browser ein bisher noch nicht vollständig empfangenes Dokument auch zu rendern bereit oder auch nur im Stande wäre, so dass ein auf solche Weise "vorausgeschickter" Statusbalken im Zweifelsfalle gar nicht erst angezeigt würde.)

Ich denke, hier irrst du.

Ich bin im Gegenteil geneigt, Sven hier Recht zu geben.

Eine solche Fortschrittsanzeige liesse sich (sofern nicht vernünftigerweise gleich clientseitig implementiert) am praktikabelsten wohl noch wohl mit unabhängigen Requests bewerkstelligen. Der eine, der den Upload vornimmt und schließlich nach Abschluss wie gewohnt eine Antwort bekommt - und davon unabhängige "Zwischen"-Requests, bspw. per AJAX, denen der Server zwischendurch immer wieder Auskunft gibt, wie viel von den (zu erwartenden, auch diese Info muss er natürlich vorab bekommen - ich weiß nicht, ob eine solche Angabe beim Request Pflichtheader ist?) Daten er bereits empfangen hat.

gruß,
wahsaga

[dedlfix]

echo $begrüßung;

Und wie ersetzt du dann den bereits losgeschickten "Balken" nach dem Ende des Uploads bspw. durch eine Bestätigungsseite?

Das Thema hatten wir doch schon vor einiger Zeit mal, als es um eine Fortschrittsanzeige bei einer längeren Berechnung ging. Man könnte eine CSS-Regel nachschieben, die bestimmte Teile der Seite ausblenden, oder ein Javascriptchen das erledigen lassen. Darüber möchte ich jetzt auch noch nicht konkret nachdenken, solange keine weiteren Details der Implementierung feststehen.

Einem Browser, der bereits ein HTML-Dokument empfangen hat, rein serverseitig ein neues HTML-Dokument unterzuschieben, dürfte schwierig werden. (Und mit irgendwelchem flush-Gebastel, womit wir nach einem bisher nur teilweise und unvollständig ausgelieferten Dokument dann noch einen "Rest" nachschieben, wollen wir ja wohl nicht anfangen.

Ebenso (der Teil ab der Klammer). Alles andere ist in meinen Augen für diesen Zweck viel zu aufwendig.

Zumal ja gar nicht gesagt wäre, dass der Browser ein bisher noch nicht vollständig empfangenes Dokument auch zu rendern bereit oder auch nur im Stande wäre, so dass ein auf solche Weise "vorausgeschickter" Statusbalken im Zweifelsfalle gar nicht erst angezeigt würde.)

Bis auf Opera machten das alle Browser im Test zu oben erwähnten Anlass mit. Und sie machen das mit voller Absicht, schon Teile des Dokuments zu rendern, bevor es komplett da ist, um bereits die Wartezeit beim Empfang sinnvoll zu nutzen. Meist können sie das nur dann nicht, wenn komplexere Strukturen zu rendern sind, wie beispielsweise Tabellen ohne Renderhilfselemente. Dir wird doch sicher schon mal aufgefallen sein, dass manche Seiten einen unruhigen Aufbauvorgang haben und teilweise Dinge noch mal hin und her schieben, bevor der Ladebalken zur Ruhe gekommen ist.

Ich denke, hier irrst du.
Ich bin im Gegenteil geneigt, Sven hier Recht zu geben.

Das macht nichts. Warten wir ab, was am Ende rausgekommen ist. Ich bin in der Lage auch Gedankengänge revidieren zu können, die sich als falsch herausstellen.

echo "$verabschiedung $name";