header_filter will stay installed in the filter chain when processing
HEAD requests to intercept and discard content bodys sent by poorly
written handlers. This work also points out the need for an optimization
in the content_length filter to not split the brigade if the next bucket
in the brigade is an EOS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89679 13f79535-47bb-0310-9956-ffa450edef68
where HEAD response headers were being repeated twice for
files greater than 32K bytes (4*AP_MIN_BYTES_TO_WRITE). This
problem in the http_header filter was exposed by the recent rewrite
of the content_length filter.
[Taketo Kabe, Bill Stoddard]
PR: 8037
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89676 13f79535-47bb-0310-9956-ffa450edef68
TLSFilter gets wiped out, breaking any response that comes through ap_die
(including the frequent '304 not modified')
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89601 13f79535-47bb-0310-9956-ffa450edef68
apr_brigade_puts(). There is still some redundancy--it'd be ideal if there
were an apr_pstrcat() variant that returned the length of the string since
it computes it (twice) anyway so we didn't have to do it yet again. Until
such a beast exists, computing the length three times is better than four.
:-/
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89516 13f79535-47bb-0310-9956-ffa450edef68
* did some code cleanups/optimizations in that function.
* updated Apache's byterange filter to handle the new prototype. added
error handling to the byterange filter should apr_brigade_partition()
ever fail, which it never will unless somebody either removes the earlier
call to apr_brigade_length() for some unknown reason or invents a new
bucket type that is of a predetermined length but which cannot be split
natively (or which has a split that might fail). might as well be
future-proof.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89363 13f79535-47bb-0310-9956-ffa450edef68
parms to form_header_field() and it overlaid some vhost structures,
resulting in a segfault in check_hostalias().
[Greg Ames, Jeff Trawick]
Note: Not being familiar with the TRACE method I compared the 2.0
output with 1.3.9 output. The only difference is that with 2.0 we
get a Content-Length header field.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89138 13f79535-47bb-0310-9956-ffa450edef68
again. The problem is that the amount of data read from the network,
is not necessarily the amount of data returned from the filters. It is
possible for input filters to add bytes to the data read from the network.
To fix the original bug, I just removed the line from ap_get_client_block
that decremented r->remaining, we allow the http_filter to do that for
us.
I have also removed an incorrect comment.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89041 13f79535-47bb-0310-9956-ffa450edef68
which corresponded to r->remaining (in ap_get_client_block). However,
ap_get_client_block was *also* adjusting r->remaining. Net result was that
PUT (and probably POST) was broken. (at least on large inputs)
To fix it, I simply removed the indirection on "readbytes" for input
filters. There is no reason for them to return data (the brigade length is
the return length). This also simplifies a number of calls where people
needed to do &zero just to pass zero.
I also added a number of comments about operations and where things could be
improved, or are (semi) broken.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@89008 13f79535-47bb-0310-9956-ffa450edef68
determine how much data is returned to the previous filter. Prior to this
change, we used a field in the conn_rec to determine how much to return.
After this change, we use an argument to ap_get_brigade. This makes it
much more obvious how things work at all levels, so that module authors
can easily determine how much data is supposed to be returned to them.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88912 13f79535-47bb-0310-9956-ffa450edef68
request, then the byterange filter should not try to redo the
work. The most common case of this happening, is a byterange
request going through the proxy, and the origin server handles
the byterange request. The proxy should ignore it.
Submitted by: Graham Leggett <minfrin@sharp.fm>
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88873 13f79535-47bb-0310-9956-ffa450edef68
told me I was wrong. I was wrong, and Greg was right. This commit
just moves the byterange filter and its related functions out of the core,
and puts them back in the HTTP specific module.
Submitted by: Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88815 13f79535-47bb-0310-9956-ffa450edef68
(header) through the filter stack, which just wrapped that response in
another set of headers.
Instead, just set the Allow header and return. The EOS will then flush that
header with the rest of the data through the header filter, and generate the
proper response.
Also, cleaned out the unused header_filter_ctx and the "len" variable from
the header filter, and added some comments here and there.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@88600 13f79535-47bb-0310-9956-ffa450edef68
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
