-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Stream] STREAM_NOTIFY_PROGRESS over HTTP emitted irregularly for last chunk of data #10031
Comments
Interestingly, I cannot reproduce this on native Windows (10), but easily on WSL. |
With the same php version? That's strange... Just speculating without checking the source (i don't understand it): could it be a problem with the OS (win11 and wsl)? I mean, maybe the OS transfers the bytes correctly, but then notifies the progress incorrectly, and php blindly passes it to the notification callback. At the same time, with this hypothesis, If that's the case, while waiting (and hoping) for an OS-level fix, a php-level fix would simply be to calculate the current chunk size ( But that's all speculation as i said. |
…regularly for last chunk of data Fixes phpGH-10031 It's possible that the server already sent in more data than just the headers. Since the stream only accepts progress increments after the headers are processed, the already read data is never added to the process. We account for this by adjusting the progress counter by the difference of already read header data and the body.
Co-authored-by: aetonsi <18366087+aetonsi@users.noreply.github.com>
Co-authored-by: aetonsi <18366087+aetonsi@users.noreply.github.com>
…regularly for last chunk of data Fixes phpGH-10031 It's possible that the server already sent in more data than just the headers. Since the stream only accepts progress increments after the headers are processed, the already read data is never added to the process. We account for this by adjusting the progress counter by the difference of already read header data and the body.
Co-authored-by: aetonsi <18366087+aetonsi@users.noreply.github.com>
* PHP-8.1: Fix GH-10031: [Stream] STREAM_NOTIFY_PROGRESS over HTTP emitted irregularly for last chunk of data
* PHP-8.2: Fix GH-10031: [Stream] STREAM_NOTIFY_PROGRESS over HTTP emitted irregularly for last chunk of data
... and thanks again @nielsdos ! |
Description
Problem
Files
file
echo.php
file
test.php
CLI commands:
Wrong output (happens irregularly):
Correct output:
Description
The file
echo.php
generates a series of 1000 consecutive"x"
s. The data is emitted with intervals of 50ms (usleep(50 * 1000)
), in 10 chunks sized 99bytes, plus one final chunk of 10bytes (99*10 + 10 = 1000).The script
test.php
fetches the data from the url/echo.php
of the local web server.file_get_contents
is passed a context with anotification
callback. This callback prints the download progress: percentage, bytes transferred, total bytes, current chunk size. The chunk size is calculated by subtracting the previous$bytes_transferred
from the current$bytes_transferred
.If you run
php test.php
multiple times, you will see that sometimes the event last 1/2STREAM_NOTIFY_PROGRESS
events are not emitted correctly.The last events should always be:
progress: 89.1% (891/1000 b) (chunksize=99)
= chunk 9progress: 99% (**990**/1000 b) (chunksize=**99**)
= chunk 10progress: 100% (**1000**/1000 b) (chunksize=**10**)
= chunk 11Instead, sometimes the last chunks are messed up:
progress: 89.1% (891/1000 b) (chunksize=99)
= chunk 9progress: 90.1% (**901**/1000 b) (chunksize=**10**)
= chunk 10. This line here is the culprit. This chunk has the correct size of the last chunk (10 bytes), but it's reported as being the 10th! In reality, the 10th chunk is still 99bytes large, and the 11th is the 10bytes one.When this problem occurs, 100% progress is never emitted (as the 10th chunk is mistaken for the 11th).
I don't think this is a problem in the communication between
php
and the web server. Any possible delay in the communication shouldn't interfere with how the chunks are passed to the notification callback. I tried runningcurl -#O
multiple times to see howcurl
receives the data. This is the command line i used (powershell):1..10 | % { curl -#LO http://localhost:8000/echo.php *>&1 | php -r "preg_match_all('/[0-9\.]+/m', stream_get_contents(STDIN), `$m);echo implode(', ', `$m[0]).PHP_EOL;" ;}
. For each iteration (1..10
), this prints every progress percentage reported bycurl
.It prints something like this:
As you can see,
curl
doesn't always report its progress, but even though it skips some reporting, it always has the correct progress percentages. It always ends with89.1
,99.0
,100.0
, which is the correct sequence.php
on the other hand sometimes ends with89.1
,90.1
.In conclusion, at the moment the
STREAM_NOTIFY_PROGRESS
event is not reliable.I cannot determine why this problem occures only sometimes. I really can't. This appears extremely frequently when the chunks are transferred with varying sizes (eg if the php script on the server calls
readfile()
, and/or if the connection to the server is not stable).PHP Version
PHP 8.1.12
Operating System
Windows 11 (10.0.22621.819)
The text was updated successfully, but these errors were encountered: