step -must- be done with a pool that will not outlive the cmd pool, from
which they may have been dynamically loaded.
This needs further review, it's committed only as a stopgap for those
who's builds I broke, sorry. Review tbc late this evening.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87699 13f79535-47bb-0310-9956-ffa450edef68
underlying (broad) bug. dav_add_response() was assuming the walk params were
a dav_walker_ctx. During the walker cleanup in Nov00, that assumption was
removed, so response errors that occurred in the cleaned sections (such as
dav_fs_delete_resource) could trigger a segfault.
Solution: add a pool to dav_walk_resource and alter dav_add_response to use
that, rather than assume the ctx is a dav_walker_ctx.
[ note there is also a pool in dav_walk_resource.resource, but that pool is
associated with the *resource* rather than the process of walking, so we
introduced another field. currently they are the same, however. ]
Found by: Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87670 13f79535-47bb-0310-9956-ffa450edef68
is to make certain that only apr_sendfile() will be used to send content with a cached file handle.
This assumes that apr_sendfile() should not rely on the position of the file pointer. I suspect that
sendfile implementations that rely on the position of the file pointer are broken and we should not
use sendfile on those platforms.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87654 13f79535-47bb-0310-9956-ffa450edef68
We copy the data when we store it in the structures, we can just return
a pointer from there, and use const data. This puts the onus back on
Apache to copy the data if it needs to modify it.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87592 13f79535-47bb-0310-9956-ffa450edef68
have MMAP, by just checking with APR, instead of using an Apache
definition which doesn't really control anything anymore.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87563 13f79535-47bb-0310-9956-ffa450edef68
problem is that some browsers send an extra line at the end of a POST
request. We use the PEEK method to determine if there is any data left
on the socket, if there is then we delay sending the response until we
have enough data to make it worthwhile. If the browser sends an extra
blank line, we don't want to delay the response at all. The only time
we use the PEEK method is to check for a second request, so this is safe
to do.
This also solves Joe Orton's problem of specifying a Content- Length
of 1 for a blank line, and having the server wait to send back a response.
The problem is that Linux (all Unix really) sends two characters \r\n for
a blank line, so specifying a C-L of 1 means that the server still sees
a \n when it PEEKs that the socket data. That \n can be safely ignored
however.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87540 13f79535-47bb-0310-9956-ffa450edef68
This also allows mod_cgid to use ap_os_create_priviledged_process,
thus allowing for SuExec execution from mod_cgid. Currently, we do
not support everything that standard SuExec supports, but at least
it works minimally now.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87524 13f79535-47bb-0310-9956-ffa450edef68
only be regenerated immediately prior to the tag and roll. Do not assume
they are current with the sources in the development tree. They should
be generated as vc5 make files, since only vc5 makefiles are readable by
both vc5 and vc6.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87479 13f79535-47bb-0310-9956-ffa450edef68
Modules are named mod_foo.so
Dynamic Libraries are named libfoo.dll, and are stored in bin/
The former ApacheCoreDll is now libhttpd.dll
Apache.exe moves to bin/
The make install now copies include, lib, and libexec
All build options are normalized, filenames adjusted appropriately
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87471 13f79535-47bb-0310-9956-ffa450edef68
