Requiring all internal classes (including those from 3rd-party
extensions) to implement Stringable if they provide __toString()
is too error prone. Case in point, our _ZendTestClass test class
was not doing so, resulting in preloading test failures after
recent changes.
Instead we automatically implement Stringable, the same as we do
for userland classes. We still allow explicit implementations,
but ignore them (normally they would result in an error due to
duplicate interface implementation). Finally, we need to be
careful about not trying to implement Stringable on Stringable
itself.
In some cases this changes the interface order, in particular the
automatic Stringable implementation will now come first.
As a followup to f34114b1fb print
the contents of arrays rather than just a generic "Array" marker.
Also drop the truncation on strings. As we no longer resolve
constants, there should be less concerns about printing very
large strings here. If someone thought it was a good idea to use
a 10k character strings as a default value in code, then it should
be fine for us to print it in reflection as well.
While our HTTP parser supports upgrade requests, the code using it does
not. Since upgrade requests are only valid for HTTP/1.1 and we neither
support any higher version, nor HTTPS yet, we do not exit early in case
of such requests, i.e. we ignore them, what is allowed by the specs.
We keep the supporting code in case we can meaningfully support upgrade
requests in the future.
Closes GH-7316.
The built-in Webserver's `on_path`, `on_query_string` and `on_url`
callbacks may be called multiple times from the parser; we must not
simply replace the old values, but need to concatenate the new values
instead.
This appears to be tricky for `on_path` due to the path normalization,
so we fail if the function is called again.
The built-in Webserver logs errors during request parsing to stderr,
but this is ignored by the php_cli_server framework, and apparently the
Webserver does not send a resonse at all in such cases (instead of an
4xx). Thus we can only check that a request with an overly long path
fails.
Closes GH-7207.
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>
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.
The primary issue was already resolved in 7c3e487289,
but the particular example used in this bug report ran into an
additional issue on PHP 8, because I forgot to drop a number of
zend_bailout calls when switch require failure to throw.
Unconditionally strip shebang lines when using the CLI SAPI,
independently of whether they occur in the primary or non-primary
script. It's unlikely that someone intentionally wants to print
that shebang line when including a script, and this regularly
causes issues when scripts are used in multiple contexts, e.g.
for direct invocation and as a phar bootstrap.
In practice, we always act as an HTTP/1.1 client, for compatibility
with servers which ignore protocol version. Sending the version in
the request will avoid problems with servers which don't ignore it.
HTTP/1.0 can still be forced using a stream context option.
Closes GH-5899.
If the CTRL-C event can't be sent to the child for whatever reason, the
test will never terminate, because `proc_close()` waits for an infinite
amount of time. Therefore, we `proc_terminate()` the child instead,
after explicitly closing the pipes.
This test failed when the free disk space is close to 2.15GB.
I see the file size in the .out file as 0.
PHP has to save the full file contents to disk (the path is in `$_FILES`)
Related to GH-5283
Closes GH-5873