This loop can block for some minutes, theoretically. Practially
however, this is a 99% non issue for a normal use case. This is
required because read() is synchronous. The PHP streams API wants
to fill its internal buffers, therefore it might try to read some
more data than user has demanded. Also, for a case where we want
to read X bytes, but neither enough data nor EOF arrives, read()
will block until it could fill the buffer. If a counterpart station
runs slowly or delivers not all the data at once, read() would
still be waiting. If we quit too early, we possibly could loose
some data from the pipe. Thus it has to emulate the read()
behaviour, but obviously not completely, just to some grade.
Reading big data amount is for sure an issue on any platforms, it
depends on the pipe buffer size, which is controlled by the system.
On Windows, the buffer size seems to be way too small, which causes
buffer congestion and a dead lock. It is essential to read the pipe
descriptors simultaneously and possibly in the same order as the
opposite writes them.
Thus, this will work with smaller buffer data sizes passed through
pipes. As MSDN states, anonymous pipes don't support asynchronous
operations. Neither anonymous pipes do support select() as they are
not SOCKETs but file descriptors. Consequently - bigger data sizes
will need a better solution based on threads. However it is much
more expencive. Maybe a better solution could be exporting a part
of the internal doing as a userspace function which could perform
some kind of lookahead operation on the pipe descriptor.
This is just the first stone, depending on the user feedback we
might go for further improvements in this area.
Some applications check a LDAP link's error code after seeing ldap_bind
fail due to a null byte bind attempt and hence incorrectly receive the
last set error code.
Fix by setting an LDAP error code before returning in this case.
This fixes a bug in libmagic where a cast to 'char' is assumed to result
in sign extension to occur. However, unqualified 'char' is unsigned on
architectures such as ARM, so the cast needs to be to 'signed char'
explicitly.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
there are multiple issues with this code
- php_stream_read() returns an unsigned val, so is >= 0
- if it read less than sizeof(a) bytes, the function operates on garbage
- result->channels is an unsigned val, so >= 0
Some environments, apparently regardless to the freetype version, output 155, while others 156. I guess we can accept both ;)
This reverts commit 592df89027.
ProxyPass is unable to provide correct PATH_INFO
as it is not aware of file path (while SetHandler is).
As we can extract PATH_INFO from PATH_TRANSLATED,
we also need to check if present in SCRIPT_NAME
and remove it.
After applying this patch.
With mod_php
_SERVER["REQUEST_URI"] /info.php/foo/bar?q=1
_SERVER["SCRIPT_NAME"] /info.php
_SERVER["PATH_INFO"] /foor/bar
_SERVER["PHP_SELF"] /info.php/foo/bar
_SERVER["QUERY_STRING"] q=1
With mod_proxy_fcgi + SetHandler
_SERVER["REQUEST_URI"] /info.php/foo/bar?q=1
_SERVER["SCRIPT_NAME"] /info.php
_SERVER["PATH_INFO"] /foo/bar
_SERVER["PHP_SELF"] /info.php/foo/bar
_SERVER["QUERY_STRING"] q=1
With mod_proxy_fcgi + ProxyPass
_SERVER["REQUEST_URI"] /info.php/foo/bar?q=1
_SERVER["SCRIPT_NAME"] /info.php
_SERVER["PATH_INFO"] /foo/bar
_SERVER["PHP_SELF"] /info.php/foo/bar
_SERVER["QUERY_STRING"] q=1
