We need to update the value even if new_value is NULL. In particular,
it should be reset back to NULL after each request if the setting was
not specified on startup. Otherwise we leave dangling pointers.
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.
We add the `is_seekable` member to `php_stdio_stream_data`, and prefer
that over `is_pipe`, since the latter is simply a misnomer. We keep
`is_pipe` for now for Windows only, though, because we need special
support for pipes there. We also fix the misaligned bitfield which
formerly took 33 bit.
First, the limitation already doesn't trigger if you copy the whole
file (i.e. use copy() or stream_copy_to_stream() and don't specify
a length). This happens because length will be 0 at the time of the
check and only later calculated based on the file size. This means
that we're already completely blowing the length limit for what is
likely the most common case, and it doesn't seem like anyone complained
about that.
Second, the premise of the code comment ("to avoid runaway swapping")
seems incorrect to me. Because this performs a file-backed non-private
mmap, no swap backing is needed for the mapping. Concerns over "memory
usage" are also misplaced, as this is a virtual mapping.
This makes the stream opening actually fail, and avoids assertion
failures when we tokenize with EG(exception) set.
Also avoid throwing an additional warning after an exception has
already been thrown.
stream_get-line repeatedly calls php_stream_fill_read_buffer until
enough data is accumulated in buffer. However, when stream contains
filters attached to it, then each call to fill buffer essentially
resets buffer read/write pointers and new data is written over old.
This causes stream_get_line to skip parts of data from stream
This patch fixes such behavior, so fill buffer call will append.
There are two related changes here:
1. Also check for S_ISCHR/FILE_TYPE_CHAR when checking for pipes, so
that we detect ttys as well, which are also not seekable.
2. Always set position=-1 (i.e. ftell will return false) when a pipe
is detected. Previously position=0 was sometimes used, depending on
whether we're on Windows/Linux and whether the FD or FILE codepath
was used.
fcgi_accept_request function is supposed to call a FastCGI implementation's
on_accept hook when entering an "accepting" stage (that is right before
calling "accept"). This hook implementation (fpm_request_accepting) updates
a worker state to an "accepting" state which is effectively an "Idle" state,
and updates counters on the scoreboard of the corresponding pool (idle++,
active--).
But this is not done when listening for client connections on a named pipe on
Windows platform. In that case a combination of
ConnectNamedPipe/WaitForSingleObject is used (to be able to catch in_shutdown
as far as I understand), but it is nonetheless functionally equivalent to
"accept" call. Also by not calling on_hook neither a worker's state is updated
to "accepting" state nor scoreboard counters are updated.
There are a few parts here:
* opcache should not be blocking signals while invoking compile_file,
otherwise signals may remain blocked on a compile error. While at
it, also protect SHM memory during compile_file.
* We should deactivate Zend signals at the end of the request, to make
sure that we gracefully recover from a missing unblock and signals
don't remain blocked forever.
* We don't use a critical section in deactivation, because it should
not be necessary. Additionally we want to clean up the signal queue,
if it is non-empty.
* Enable SIGG(check) in debug builds so we notice issues in the future.
The php_stream_read() and php_stream_write() functions now return
an ssize_t value, with negative results indicating failure. Functions
like fread() and fwrite() will return false in that case.
As a special case, EWOULDBLOCK and EAGAIN on non-blocking streams
should not be regarded as error conditions, and be reported as
successful zero-length reads/writes instead. The handling of EINTR
remains unclear and is internally inconsistent (e.g. some code-paths
will automatically retry on EINTR, while some won't).
I'm landing this now to make sure the stream wrapper ops API changes
make it into 7.4 -- however, if the user-facing changes turn out to
be problematic we have the option of clamping negative returns to
zero in php_stream_read() and php_stream_write() to restore the
old behavior in a relatively non-intrusive manner.
By adding a flag to avoid forced fstat for includes. The two fstats
will happen back to back and we don't care about a possible
invalidation.
I was hoping to move this higher up in the stack and make the
ISREG check somewhere in fsizer of fixup, but this doesn't really
seem to be possible. E.g. an FP stdin handle will not be a regular
file but of course needs to be allowed. Additionally custom stream
wrappers may not implement this functionality.
Nikita Popov