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");
- We don't need libtool to build sapi/cli on Darwin.
- You want the sapi/cli build line to be in sapi/cli, not Makefile.global.
- We want the sapi/cli build line to be in sapi/cli, not Makefile.global.
- He can go about his business.
- You can go about your business.
- Move along.
- Move along. Move along.
@ getallheaders() as an alias to it. Also added apache_response_headers()
@ which returns the current response headers from Apache.
Renamed getallheaders() to apache_request_headers() and kept
getallheaders() as an alias to it. Also added apache_response_headers()
which returns the current response headers from Apache.
This allows use of PHP in:
Client-side script in Internet Explorer
Windows Scripting Host
ASP and ASP.NET pages
It's mostly working... give it a go.
You will need to regsvr32 the php4activescript.dll manually.
with development version of Apache, whose version strings end in "-dev",
eg "Apache/2.0.37-dev".
PR: 17233
Submitted by: Dale Ghent <daleg@elemental.org>
some mysterious reason never made their way from sapi/apache to
sapi/apache2filter when it was first written PR: 16629
* change the allowed locations of php_admin_value (and php_admin_flag to
match) to ACCESS_CONF instead of OR_NONE to match sapi/apache. No
idea why it was ever OR_NONE. PR: 16489
on the second pass through the post_config. Now we only avoid the
initialization only on the first DSO load, and on all subsequent loads
we rerun the init code.
the static string we were using to set an initialization flag
would get remapped to a different location when Apache reloaded
the DSO, causing us to not run our initialization routines.
Submitted by: Justin Erenkrantz <jerenkrantz@apache.org>
Reviewed by: Aaron Bannert (I added the big comment too)
Submitted by: Justin Erenkrantz <jerenkrantz@apache.org>
Reviewed by: markonen
# A stopgap measure while we try to find a "real"
# solution, if one exists.
This patch makes sure that any startup actions that are performed
for PHP don't happen until the second load (the second call to
the post_config hook), and it also prevents subsequent calls
to the initialization routines.
Suggested By: Cliff Woolley
PR: 16475, 16754
- Use the PHP_CFLAGS when compiling the php4 module in apache tree.
- Use the apache include dir only when compiling sapi/apache
o Fixes the fnmatch.h issue Wez complained about :)
allows the specification of the php.ini directory from within the Apache
configuration. If left unset, the default is to defer to the hard-coded
php paths. When set, the supplied path is made relative to Apache's
internal ServerRoot setting.
Example:
PHPINIDir "conf"
# PHP will now look in the ServerRoot/conf directory for the php.ini file
server context was set. Now if that happens we simply don't log against
any particular server config (vhost).
Obtained from bug report by: Balazs Nagy <js@iksz.hu>
filter chain instead of just down the rest of the chain. This fix will
speed up some unnecessary overhead introduced in the last patch.
Suggested by: Cliff Woolley <jwoolley@apache.org>
to do some trickery with the server_context to make sure it is always
valid within the current thread.
This patch makes sure the server_context is created in apache's
post_read_request hook phase, and then registeres a cleanup that
will NULL out the server context when the request goes out of scope.
Then, inside the output filters, if the server_context is null we
throw an error. Finally, instead of saving the output filter in
the server_context, now we store the entire request_rec pointer
in there.
POST bodies appear to be working now, although they are very inefficient.
The input filter is still just realloc()ing for whatever data comes
down the input pipe, and then sending this to PHP. This means that
we are doing some really nasty memory management on big POST bodies.
For now this it allows for unlimited input bodies, which means that
a big POST could potentially DoS a box by making it run out of memory.
We might want to put a limit on here just in case, at least until
we figure out how to consume input data more efficiently into php.
Apache 2 the input and output filter contexts are kept unique. We now
only depend on SG(server_context) for each request, and assume that
the same thread will process the entire request. At some point it
would be wise to separate the input and output contexts.