controversial change, because this is kind of HTTP specific. However
many protocols should be able to take advantage of this kind of
information. I expect that headers will need one more layer of
indirection for multi-protocol work, but this is a small step in
the right direction.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88580 13f79535-47bb-0310-9956-ffa450edef68
Add a debug assertion to verify that c->remain is zero when a new
request starts. ap_http_filter() does the wrong thing otherwise.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88540 13f79535-47bb-0310-9956-ffa450edef68
- explicitly include apr_lib.h since ap_config.h doesn't
- use apr_want.h where possible
- use APR_HAVE_ where possible
- remove some unneeded includes
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88060 13f79535-47bb-0310-9956-ffa450edef68
*) fix terminate_header: don't assume anything about the brigade (especially
that its last bucket is a shared/heap bucket)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88032 13f79535-47bb-0310-9956-ffa450edef68
the header string. This allows us to clean up the header handling a bit,
because we don't need to compute the correct length before we can create
the headers.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88029 13f79535-47bb-0310-9956-ffa450edef68
hack to fix the bug, but it will need to be fixed for real. If
we find an error while sending out a custom error response, we back
up to the first non-OK request and send the data. Then, when we send
the EOS from finalize_request_protocol, we go to the last request,
to ensure that we aren't sending an EOS to a request that has already
received one. Because the data is sent on a different request than
the EOS, the error text never gets sent down the filter stack. This
fixes the problem by finding the last request, and sending the data
with that request.
PR: 7165
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88000 13f79535-47bb-0310-9956-ffa450edef68
basically a straight port of the 1.3 module to 2.0. The MPMs need to be
modified a bit to work with mod_status, but prefork, mpmt_pthread, and
dexter have already been changed. I will fix perchild tonight. There
is a lot of common code that can be abstracted, and there seems to be a
small bug with regard to what mpmt_pthread and dexter report as current
connections. ExtendedStatus does work again, although until the bug
mentioned above is fixed, it isn't as useful on mpmt_pthread and dexter.
Next week, I will look at allowing other modules to add data to the
STATUS page and possibly to the scoreboard itself.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87949 13f79535-47bb-0310-9956-ffa450edef68
or absense of a file. finfo.filetype is defined as 0 if APR_NOFILE,
or a non-zero value if the file could be apr_stat()'ed.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87933 13f79535-47bb-0310-9956-ffa450edef68
"-999999" where that is past the end of the file, we should return
a PARTIAL CONTENT status code, and return the whole file as one big
byterange. This matches the 1.3 handling now. [Ryan Bloom]
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87885 13f79535-47bb-0310-9956-ffa450edef68
handlers will send their data down the filter stack, but 1.3 handlers will
just return, giving us a Content-Length of 0. Since we can't send a C-L
of 0 just because it is a HEAD request, we search the headers_out table
for a 0 C-L if it is a HEAD request. The problem is that some filters
will not allow (includes_filter) a C-L to be computed, so we end up without
a C-L header in headers_out. Thus, when we do a strcmp against the header
value and "0", we seg fault, because the header value is NULL.
To fix this, we grab the element from the header table, and make sure it
isn't NULL before doing the strcmp.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87870 13f79535-47bb-0310-9956-ffa450edef68
instead of using ap_bucket_read. It also lets ap_die handle the fact that
the filter returned the error.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87867 13f79535-47bb-0310-9956-ffa450edef68
by sending a brigade where the first bucket is an error_bucket.
This bucket is a simple bucket that stores an HTTP error and
a string. Currently the string is not used, but it may be needed
to output an error log. The http_header_filter will find this
bucket, and output the error text, and then return
AP_FILTER_ERROR, which informs the server that the error web page
has already been sent.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87863 13f79535-47bb-0310-9956-ffa450edef68
bug where we were using the byterange filter to filter an error, which
caused us to close the connection before we had sent any data. Currently,
we only keep the three most important filters, but we may need to add more
in the future. I am mostly thinking of the charset translation filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87854 13f79535-47bb-0310-9956-ffa450edef68
it also has to happen after ap_basic_http_header. Otherwise, we don't
set r->connection->keepalive correctly, and it can be -1 for requests that
don't support keepalive. This moves ap_basic_http_header to above the
call to set_keepalive (after reversing the previous patch), which should
be perfectly safe, while still fixing the original bug.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87824 13f79535-47bb-0310-9956-ffa450edef68
function decl's and CORE_PRIVATE header info should all move into this
header.
Start with moving the filter function declarations.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87808 13f79535-47bb-0310-9956-ffa450edef68
[the context of] a new filter ("OLD_WRITE").
Further information/discussion of this patch is available on new-httpd
between Jan 16 and Jan 23, 2001.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87804 13f79535-47bb-0310-9956-ffa450edef68
copied natively. This will only ever happen if a bucket can be split
but not copied, because we read the bucket in apr_brigade_partition if
we can't split it. Regardless, this is much safer. This should also fix
all of the problems with the byterange filter.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87793 13f79535-47bb-0310-9956-ffa450edef68
return -3 for every HEAD request, which in turn made us call ap_die. Of
course, if we didn't have a 200 status (say we had a 206), then we would
seg fault, because we would end up sending down a second EOS bucket, which
would in turn make us call the byterange filter again, but at this point,
we hadn't cleaned up the byterange ctx structure, because it was never
supposed to be called again.
This was biting us on apache.org, where we had a HEAD request for
bytes=100- for a file. This was a major seg fault. We are better off
just returning OK is much safer.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@87788 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
