multipart/form-data boundaries larger than the read buffer result in erroneous
parsing, which violates data integrity.
Limit boundary size, as allowed by RFC 1521:
Encapsulation boundaries [...] must be no longer than 70 characters, not
counting the two leading hyphens.
We correctly parse payloads with boundaries of length up to
FILLUNIT-strlen("\r\n--") bytes, so allow this for BC.
When bug 77574[1] has been fixed, the fix only catered to variables
retrieved via `getenv()` with a `$varname` passed, but neither to
`getenv()` without arguments nor to the general import of environment
variables into `$_ENV` and `$_SERVER`. We catch up on this by using
`GetEnvironmentStringsW()` in `_php_import_environment_variables()` and
converting the encoding to whatever had been chosen by the user.
[1] <https://bugs.php.net/bug.php?id=75574>
Closes GH-7928.
We need to avoid storing it in the first place, as we don't
really have a good place to release it later. If headers haven't
been sent yet, send_headers will do this. sapi_deactive happens
too late in the shutdown sequence and will result in leak reports.
zend_double_to_str() converts a double to string in the way that
(string) would (using %.*H using precision).
smart_str_append_double() provides some more fine control over
the precision, and whether a zero fraction should be appeneded
for whole numbers.
A caveat here is that raw calls to zend_gcvt and going through
s*printf has slightly different behavior for the degenarate
precision=0 case. zend_gcvt will add a dummy E+0 in that case,
while s*printf convert this to precision=1 and will not. I'm
going with the s*printf behavior here, which is more common,
but does result in a minor change to the precision.phpt test.
This makes debug_print_backtrace() use the same formatting as exception
backtraces. The only difference is that the final #{main} is omitted,
because it wouldn't make sense for limited backtraces, and wasn't there
previously either.
To fix https://bugs.php.net/bug.php?id=77372 and improve support of `<input type="file" name="files" multiple webkitdirectory>` I introduced another item to the `$_FILES` array called `full_path`, containing the full filename, as supplied by the user-agent.
Co-authored-by: Björn Tantau <bjoern@bjoern-tantau.de>
This PR corrects misspellings identified by the check-spelling action.
The misspellings have been reported at jsoref@b6ba3e2#commitcomment-48946465
The action reports that the changes in this PR would make it happy: jsoref@602417c
Closes GH-6822.
In the case of a stream with no filters, php_stream_fill_read_buffer
only reads stream->chunk_size into the read buffer. If the stream has
filters attached, it could unnecessarily buffer a large amount of data.
With this change, php_stream_fill_read_buffer only proceeds until either
the requested size or stream->chunk_size is available in the read buffer.
Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
Closes GH-6444.
Port the main php_cli_server.inc to use ephemeral ports, thus
allowing CLI server tests to be parallelized.
A complication here is that we also need to give each test a
separate doc root, to avoid index.php files writing over each
other.
Closes GH-6375.
When an input variable name contains a non matched open bracket, we not
only have to replace that with an underscore, but also all following
forbidden characters.
A time limit can be set on PHP script execution via `set_time_limit` (or .ini file).
When the time limit is reached, the OS will notify PHP and `timed_out` and `vm_interrupt`
flags are set. While these flags are regularly checked when executing PHP code, once the
end of the script is reached, they are not checked while invoking shutdown functions
(registered via `register_shutdown_function`).
Of course, if the shutdown functions are implemented *in* PHP, then the interrupt flag
will be checked while the VM is running PHP bytecode and the timeout will take effect.
But if the shutdown functions are built-in (implemented in C), it will not.
Since the shutdown functions are invoked through `zend_call_function`, add a check of the
`vm_interrupt` flag there. Then, the script time limit will be respected when *entering*
each shutdown function. The fact still remains that if a shutdown function is built-in and
runs for a long time, script execution will not time out until it finishes and the
interpreter tries to invoke the next one.
Still, the behavior of scripts with execution time limits will be more consistent after
this patch. To make the execution time-out feature work even more precisely, it would
be necessary to scrutinize all the built-in functions and add checks of the `vm_interrupt`
flag in any which can run for a long time. That might not be worth the effort, though.
It should be mentioned that this patch does not solely affect shutdown functions, neither
does it solely allow for interruption of running code due to script execution timeout.
Anything else which causes `vm_interrupt` to be set, such as the PHP interpreter receiving
a signal, will take effect when exiting from an internal function. And not just internal
functions which are called because they were registered to run at shutdown; there are
other cases where a series of internal functions might run in the midst of a script. In
all such cases, it will be possible to interrupt the interpreter now.
Closes GH-5543.
Currently, disabling a function only replaces the internal
function handler with one that throws a warning, and a few
places in the engine special-case such functions, such as
function_exists. This leaves us with a Schrödinger's function,
which both does not exist (function_exists returns false) and
does exist (you cannot define a function with the same name).
In particular, this prevents the implementation of robust
polyfills, as reported in https://bugs.php.net/bug.php?id=79382:
if (!function_exists('getallheaders')) {
function getallheaders(...) { ... }
}
If getallheaders() is a disabled function, this code will break.
This patch changes disable_functions to remove the functions from
the function table completely. For all intents and purposes, it
will look like the function does not exist.
This also renders two bits of PHP functionality obsolete and thus
deprecated:
* ReflectionFunction::isDisabled(), as it will no longer be
possible to construct the ReflectionFunction of a disabled
function in the first place.
* get_defined_functions() with $exclude_disabled=false, as
get_defined_functions() now never returns disabled functions.
Fixed bug #79382.
Closes GH-5473.
We switch the cookie value parsing function from `php_url_decode()` to
`php_raw_url_decode()`, so that cookie values are now parsed according
to RFC 6265, section 4.1.1. We also refactor to remove duplicate code
without changing the execution flow.
After taking a more detailed look at our commonly failing timeout
tests... turns out that most of them are useless as written and
don't test what they're supposed to.
This PR has a couple of changes:
* Tests for timeout in while/for/foreach should just have the loop
as an infinite loop. Calling into something like busy_wait means
that we just end up always testing whatever busy_wait does.
* Tests for timeouts in calls need to be based on something like
sleep, otherwise we'd have to introduce a loop, and we'd end up
testing timeout of the looping structure instead. Using sleep only
works on Windows, because that's the only system where sleep counts
towards the timeout. As such, many of those tests are now Windows only.
* Removed some tests where I don't see a good way to test what they're
supposed to test. E.g. how can we test a timeout in eval() specifically?
The shutdown function tests are marked as XFAIL, as we are currently
missing a timeout check in call_user_function. I believe that's a
legitimate issue.
Closes GH-4969.
Another stab in the dark to fix the intermittent failures of timeout
tests on macos CI: We're using ITIMER_PROF, which means that the
timer counts against user+system time. The "busy" wait loop counts
against real time. Currently it calls microtime() on every iteration.
If that call is implemented as a syscall rather than going through
vDSO or commpage we might be seeing many context switches here which
drive up the real time, but not user or system time.
See if making the loop busier and calling microtime() less helps the
situation.
