Bug #75910 [Com]: convert.base64-encode omits padding bytes
Edit report at https://bugs.php.net/bug.php?id=75910&edit=1
ID: 75910
Comment by: kazkiti0702 at gmail dot com
Reported by: me at levisflorian dot name
Summary: convert.base64-encode omits padding bytes
Status: Verified
Type: Bug
Package: Streams related
Operating System: macOS 10.13.3 (via brew)
PHP Version: 7.2.2
Assigned To: pollita
Block user comment: N
Private report: N
New Comment:
It doesn't seem to be fixed even in the current latest version.
The result of my experiment
[Behavior by version]
7.4.5 dGVz
7.3.15 dGVz
7.2.30 dGVz
7.2.28 dGVz
7.2.26 dGVz
7.2.20 dGVz
7.2.1 dGVz
7.2.0 dGVz
7.1.33 dGVzdA==
7.0.33 dGVzdA==
5.6.40 dGVzdA==
5.5.38 dGVzdA==
5.5.30 dGVzdA==
5.4.45 dGVz
5.3.29 dGVz
Previous Comments:
------------------------------------------------------------------------
[2019-03-22 19:19:15] me at levisflorian dot name
Hi,
what pollita explained - if I understand correctly - make senses.
I have some questions:
- is there something in the stream telling it's the end?
- is there a way to do the padding "manually"?
------------------------------------------------------------------------
[2019-03-14 15:24:48] pollita@php.net
Looking at this, I think your expected is backwards.
You *should* expect:
encode - low-level - memory = dGVz
decode - low-level - memory = test
encode - low-level - temp = dGVz
decode - low-level - temp = test
Which is still not what you get, of course, but before any fixing work is done, we should agree on
what's broken.
In the encode cases (let's ignore decode for the moment, but there may be a hidden issue there
too) a partial block has been written to the stream (base64 uses 3-byte input blocks), meaning that
on read, we don't know if the string is done (and we should nil bad) or if more data will
eventually come (and we should block). The fact that the stream hasn't been closed means that
we should be assuming that additional data will come, ergo we should block, and we should NOT get a
second block of encoded data out of the filter.
Decode may have a similar issue if we fed it non-block-aligned input (not a multiple of 4-chars),
but I haven't verified that either way yet.
------------------------------------------------------------------------
[2019-03-14 12:09:46] alessandro dot lai85 at gmail dot com
It seems that this bug is not limited to macOS, and it's affecting PHP 7.2.0 up to the latest
7.3 (which is 7.3.3 RN).
Proof: https://3v4l.org/NnFV2
------------------------------------------------------------------------
[2018-09-20 05:13:08] tenzzor at gmail dot com
Hi guys. Found the same issue.
I added a patch, which I think might be more generic solution.
In case of filtered stream, while loops until eof on stream. However, when we successfully read from
stream and reached EOF on stream, flags are still set to NORMAL, next iteration won't happen,
because there is EOF and filter is never notified of EOF.
This does not happen on php://memory stream right now, because on read it returns all data up to
EOF, but does not mark stream as EOF. Then on next read it figures there is no more data in buffer,
marks stream as eof and returns 0 read.
------------------------------------------------------------------------
[2018-07-08 18:01:11] cmb@php.net
Confirmed: <https://3v4l.org/HFW1e>.
Apparently, this regression has been introduced by commit
0a45e8f[1]. Sara, could you please have a look at this?
[1] <https://github.com/php/php-src/commit/0a45e8f096a04464bda6277c6f3d0b5461737a27>
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=75910
--
Edit this bug report at https://bugs.php.net/bug.php?id=75910&edit=1
Thread (9 messages)