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
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
that does not add a content-length. For example, mod_autoindex doesn't
set a content-length, but the byterange filter requires one. We fix this
by computing the content-length in the byterange filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87389 13f79535-47bb-0310-9956-ffa450edef68
blocking and non-blocking reads. This allows us to use the mode parameter
passed to a filter to read from the bucket correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87256 13f79535-47bb-0310-9956-ffa450edef68
files need to specifically include stdio.h, or a particular apr_*.h
header.
*) Adjust callers of apr_create_process() to deal with the extra "const"
*) Add "const" to args of ap_os_create_privileged_process()
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87080 13f79535-47bb-0310-9956-ffa450edef68
modules to not have to muck with the output_filter after it creates the
sub-request. Without this change, modules that create a sub-request have
to manually edit the output_filters, and therefore skip the sub-request
output_filter. If they skip the sub-request output_filter, then we end
up sending multiple EOS buckets to the core_output_filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87065 13f79535-47bb-0310-9956-ffa450edef68
if/when we compute the content-length. There are just a few cases now:
1) We already have all the data
2) We don't have all the data and:
2a) This is a 1.1 request but we can't chunk
2b) The is a keep-alive request
In the future, we probably want to modify this to not
be a keep-alive request.
This filter always buffers 9K of data. The reason is simple, the core will
buffer 9K at a time anyway, and there is a chance that we may get the end
of the request before we hit 9K. This increases our chances of being able
to send a c-l.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87055 13f79535-47bb-0310-9956-ffa450edef68
ap_send_error_response to the http_header filter. The reason for the move,
is that the header filter takes care of all header processing now. Without
this change, we were sending garbage data to the client whenever we sent
304 responses.
Submitted by: Brian Havard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87003 13f79535-47bb-0310-9956-ffa450edef68
ugly, but it does proxy pages. This even fixes the content-type bug
that I introduced yesterday sometime. As soon as BUFF is removed from
the FTP proxy, the buff.c and buff.h files need to go away.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86988 13f79535-47bb-0310-9956-ffa450edef68
the content-length is 0. The problem is that the C-L on a HEAD response
has to be the correct C-L, but if a handler returns saying the handled
the request without sending data, the core sends an EOS down the filter
stack, and we compute a 0 C-L.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86976 13f79535-47bb-0310-9956-ffa450edef68
chance to compute the proper content-length before we try to send a set
of headers. If a handler wants to ignore the HEAD method, then it can
either just return from the handler function or pass an EOS bucket down
the filter stack. Either method will still get the headers sent to the
client.
This change allows handlers to actually run the request like it is a GET
request. The core itself will then ensure that no body is sent. This
allows us to get more information about the request before sending out the
headers for the HEAD request.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86954 13f79535-47bb-0310-9956-ffa450edef68
header file. The only time that the C-L should be zero is if there is
no body. Zero is a valid content-length, but the only time that we ever
really send it is on a HEAD request right now, and that is incorrect.
The HEAD response should have the actual content's length.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86953 13f79535-47bb-0310-9956-ffa450edef68
