After the sigsetjmp change, this is patch #2 in an effort to get some
sanity restored to signal handling in PHP.
This patch does two things. First, it makes it possible to reset the
timeout without resetting the signal handlers. This is important for
cases where an extension may have deferred signals in its MINIT in order
to implement critical sections. It also lays the groundwork for cleaning
up our signal handling and perhaps eventually implementing our own
signal deferring mechanism so we can have true critical sections.
The second thing this does is to make it possible to terminate the current
child process (only for Apache1 at the moment) on a timeout. There are
a number of extensions that are unhappy about being longjmp'ed out of
and when this happens on a timeout they are left in an inconsistent state.
By turning on exit_on_timeout you can now force the process to terminate
on a timeout which will clean up any hanging locks and/or memory left
hanging after the longjmp.
This adds proto_num to request_info. It is defaulted to HTTP 1.0 (1000)
such that it has a valid value even if the underlying sapi doesn't set it
correctly. It is then used to determine if a 302 or a 303 should be sent
on a Location redirect. Any non GET/HEAD HTTP 1.1 redirect will get a 303
instead of a 302 to be compatible with the HTTP spec.
make PHP register the variable, returning 0 shouldn't. The new length of
the variables being filtered is now returned in the new_val_len argument
of the function.
into entities or use some other mechanism which causes the filtered data
to be longer than the original data. Ergo, pass in the address of the
buffer instead so the filter is free to reallocate it.
non-privileged user the web server is running as. this is useful
for creating shared memory segments which need to be accessed by
the child processes/threads.
this is necessary, when you want to take over control of a connection
and the web server is doing stupid things by default (like enabling
chunked transfer encoding for no reason).
calls.
Revert the change to the sapi_add_header_ex interface.
Fix various bugs:
1. header("HTTP/1.0 306 foo");
header("Location: absolute-uri");
did not work in combination with several SAPI modules, because
http_status_line was never properly reset. And thus, all SAPI
modules which looked at http_status_line ignored the changed
http_response_code.
2. The CGI SAPI did not send out the HTTP status line at all, if
http_status_line had not been set explicitly by calling
header("HTTP/1.0 200 foo");