fixed, but it is good enough for now. The idea is that headers shouldn't
flow through the BUFF anymore. Now, we have a header filter that is
called at the end of the request-filter chain. This filter writes the
headers directly to the connection filters.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86687 13f79535-47bb-0310-9956-ffa450edef68
they are currently storing. There is no way we can force them to flush,
but we can advise. This also adds the code to ap_rflush to use flush
buckets, although it isn't enabled yet. I will enable it once we remove
buff from the code. I also removed all calls to ap_rflush that are either
immediately before or immediately after a call to ap_finalize_protocol.
ap_finalize_protocol sends an EOS bucket, which also advises filters to
flush their data, so having both calls right next to each other is
redundant.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86619 13f79535-47bb-0310-9956-ffa450edef68
brigade generated by the sub-request. If this is not done, then the
main-request's core_output_filter will get very confused, as will any other
filter in the main-request filter-stack that looks for EOS.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86618 13f79535-47bb-0310-9956-ffa450edef68
get dechunking working
verify that infrastructure for input filters works
(use existing AddInputFilter directive)
Unlike with my previous patch, ap_get_client_block() saves state between
calls in the core's per-request dir config.
Unlike with my previous patch, HTTP_IN keeps a count of remaining bytes
in the conn_rec. Code that needs to prod it to deliver a certain amount
of request body plays with conn_rec->remain directly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86613 13f79535-47bb-0310-9956-ffa450edef68
for CORE_EXPORT to AP_CORE_DECLARE (namespace protecting the wrapper)
and retitled API_EXPORT as AP_DECLARE and APR_EXPORT as APR_DECLARE.
All _VAR_ flavors changes to _DATA to be absolutely clear.
Thank you Greg, for the most obvious suggestion.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86609 13f79535-47bb-0310-9956-ffa450edef68
a pointer to a static structure. The ap_foo_type functions have also been
replaced with simple macro calls. I am going to replace the
ap_bucket_(read|split|setaside|destroy) functions with macros soon.
Reviewed by: Will Rowe
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86597 13f79535-47bb-0310-9956-ffa450edef68
pointers are replaced with a global table that allows modules to register
their bucket types. Those bucket types are then allowed to be used in
the server processing. This also required removing all direct calls to
those functions. The ap_bucket type has an index into an array, so in
each ap_bucket_* function, we use that index to find the correct set of
functions.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86575 13f79535-47bb-0310-9956-ffa450edef68
specific value, and therefore it belongs in the ap_bucket_file type,
which was also created with this commit. ap_bucket needs to be as generic
as possible to make it easily extensible, which means we have to keep
the generic ap_bucket type very separate from ap_bucket_foo.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86568 13f79535-47bb-0310-9956-ffa450edef68
values for the length, -1, 0, and a positive number. -1 means that the
next filter should return all the data it has, the current filter will
take care to ensure that the protocol is followed. Most filters will
never use this, because it implies they are implementing a conn_based
input filter. 0 means give me exactly one line of data. A positive
number means give me a maximum of n bytes.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86567 13f79535-47bb-0310-9956-ffa450edef68
currently, but it is a step in the right direction. Input filtering
should be slowly improving from here on out.
Submitted by: Greg Ames, Ryan Bloom, Jeff Trawick
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86547 13f79535-47bb-0310-9956-ffa450edef68
conn_rec. Since all requests on a given connection use the same
core_output_filter, the ctx in that filter has the correct lifetime
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86494 13f79535-47bb-0310-9956-ffa450edef68
send by apr_send would cause unsent data in the read buffer to
get clobbered. Complete making send_the_file handle partial
writes to the network.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86485 13f79535-47bb-0310-9956-ffa450edef68
Windows 95/98 with binaries compiled on Windows NT. The solution is not specific
toWindows though. Catch up on some CHANGES logging.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86476 13f79535-47bb-0310-9956-ffa450edef68
until we have found a LF, then we send the data up to the previous filter.
I have test on Linux with both Linux's telnet and Win 98 telnet. Win98
uses a char-at-a-time, so this should solve the problem.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86457 13f79535-47bb-0310-9956-ffa450edef68
without sendfile. This also makes the apr_hdtr_t type available on
all platforms, regardless of whether apr_sendfile is defined or not.
Submitted by: Brian Havard and Ryan Bloom
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86437 13f79535-47bb-0310-9956-ffa450edef68
structure. This changes the core_output_filter to use a brigade inside
the conn_rec. Think of this as analagous to the BUFF in the conn_rec.
The idea is that if we have pipelined requests, and it isn't worth it to
send the last bit of data from the first request, we want to save that
extra bit of data to the conn_rec, so that the next request sends it
automatically.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86433 13f79535-47bb-0310-9956-ffa450edef68
The reason is really, really simple. If we ever choose to mix clib and
dos error codes, they criss-cross and don't line up, but they share the
same number space. As I wrote the new APR_IS_ERROR macros, I realized
we were about to shoot ourselves in the foot.
These changes nearly entirely affect Win32 only. The next big patch will
affect all of the rv == APR_ENOENT type problems throughout the system.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86416 13f79535-47bb-0310-9956-ffa450edef68
1) separate filter lists hanging off the r and the c
requests start off with the same filter list as the connection
the input filter list is not initialized for subrequests
internal redirects start off with the same filter list as the
connection
2) AddInputFilter directive (blatant rip-off of Ryan's AddOutputFilter
directive); as with AddOutputFilter, the network is implicitly to the
right of the specified filter list; this may not be the most
intuitive way to specify the filters; not sure yet
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86403 13f79535-47bb-0310-9956-ffa450edef68
request_rec. This means that a conn_rec must be supplied when calling
ap_add_filter. The reason for this change is that we need to be able to
add the core_filter (whether or SSL or not) before we try to read the
request. This way, if a request fails, we can actually send the error
page back to the client. With this change, we add the core filter to the
conn_rec during the pre-connection phase.
Submitted by: Ryan Bloom, Jeff Trawick, and Greg Ames
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86392 13f79535-47bb-0310-9956-ffa450edef68
writev_it_all() in case we have another brigade to process.
Otherwise, nbytes is bogus for the second brigade and
writev_it_all() doesn't know when to quit (it loops).
In writev_it_all(), when compensating for bytes already sent
don't go beyond the number of iovs we were passed on input.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86391 13f79535-47bb-0310-9956-ffa450edef68
brigades across multiple calls until MAX_IOVEC_TO_WRITE or
MIN_SIZE_TO_WRITE thresholds are hit. This implementation does not attempt
to coalesce bytes. Moving a bit further down the filter learning curve...
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86389 13f79535-47bb-0310-9956-ffa450edef68
1) don't compute md5 if we have a content filter; it is almost always wrong
2) add note about adding md5 filter in the future; this can be done
3) delete some APACHE_XLATE/CHARSET_EBCDIC baggage associated with md5
digest support; part of this deleted baggage is a segfault on
subrequests referencing r->rrx (which is not allocated for subrequests)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86385 13f79535-47bb-0310-9956-ffa450edef68
FIN/EOF or error. This meshes with what getline() looks for. It isn't
perfect, but it avoids some nasty loops consuming all available storage
on http/1.1 connections. In keepalive state, we call getline to read the
next request... getline() calls core_input_filter() (indirectly)...
core_input_filter() calls apr_recv() which returns APR_SUCCESS/0 bytes
to signal FIN/EOF. But core_input_filter() returned a bucket with length
zero to getline(), so getline() called core_input_filter() again.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86379 13f79535-47bb-0310-9956-ffa450edef68
in ap_new_connection, but that is bogus, because then other modules can't
put their own filter in. Now, we do this in a new pre-connection hook
function. Later, we will want to add some checking to make sure that this
is really an HTTP request that we are adding the filter for.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86364 13f79535-47bb-0310-9956-ffa450edef68
This implementation is limited to coalescing a single string of small (< MIN_BUCKET_SIZE)
buckets into one large bucket. If a brigade contains a string of small buckets followed by a
large bucket followed by another string of small buckets, only the first string will be coalesced.
This implementation works very well with the output generated by mod_autoindex though.
The number of iovecs handled by http_core is reduced to three from over a thousand for my
test case.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86355 13f79535-47bb-0310-9956-ffa450edef68
