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
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
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
ap_save_brigade. This function does not try to save the actual brigade to
a specific location. If just traverses the brigade, calls setaside if
it is available and concatenates it with a previously setaside brigade.
The resulting brigade is returned to the caller for them to save it to
the appropriate location.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86370 13f79535-47bb-0310-9956-ffa450edef68
check that a setaside routine is defined for the bucket before attempting to call it. Not sure
at all if we even want to keep this routine as it does not allow using filter->ctx for other
purposes.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86365 13f79535-47bb-0310-9956-ffa450edef68
registrations is actually modified. This allows Apache to server
pages again. (Before this, every ap_add_filter() silently failed
and so output content went to the bit bucket.)
Also, repair some comments and un-namespace-protect a now-static
function.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86255 13f79535-47bb-0310-9956-ffa450edef68
is add part of the infrastructure. Namely:
1) filter list in the conn_rec, which is where the input filter list
must live
2) Split the register_filter into multiple functions, one to register
input filters the other to register output filters.
3) Modify existing modules so they still work.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86251 13f79535-47bb-0310-9956-ffa450edef68
to get to the filter name from the filter itself. This is useful for
modules like mod_perl, which have one filter function that does different
things based on the name used when the filter was inserted.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86221 13f79535-47bb-0310-9956-ffa450edef68
that have been previously registered with the server. Currently the
directive is only valid inside the config file, but once the Options
directive is tweaked a bit, I would feel more comfortable exposing this
directive to htaccess files.
As a part of making adding this filter, I removed the ctx pointer from the
ap_add_filter prototype. The problem is that the core is the thing that
is actually inserting the filter into the filter stack, but the core doesn't
know how to allocate memory for each filter. The solution is to have the
filters themselves be responsible for allocating the ctx memory whenever
it is required.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86220 13f79535-47bb-0310-9956-ffa450edef68
done by adding a flag to the request_rec. When ap_pass_bucket sees an
EOS bucket, the flag is set. If the flag is still unset when
ap_finalize_request is called, then ap_finalize_request sends an EOS. This
fixes the problem with chunking and CGI.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86202 13f79535-47bb-0310-9956-ffa450edef68
new AP_RING macros. Most of this commit is fairly pedestrian as you
would expect, but I had to redo the chunking filter because of the
amount of pointer juggling it did. I have done some minimal testing
of this patch and it seems to work.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86178 13f79535-47bb-0310-9956-ffa450edef68
we use a modified LIFO. It is modified, because if we add a filter while
in the middle of another filter, the added filter gets put in after the
current filter. This requires that the server is smart about which filters
are added when. This should be handled by the HTTP protocol, but we will
want to keep and eye on things for a little while.
This change is necessary, because currently when we add a filter it goes
after the last filter of the same type. This is broken whenever we want
to add a filter that has a dependancy. Think about the core and chunking
filters. They are of the same type, and core is always added first. When
we go to insert chunking, it gets added, but it is never called.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86161 13f79535-47bb-0310-9956-ffa450edef68
to the filter stack. This makes the chunking filter work. Without this,
the core_filter is installed in the insert_filters hook, when we get
to the ap_send_http_headers function, we insert the chunking filter, but
it has been installed after the core_filter. This means the chunk_filter
is never called.
This reverses this. The core_filter is installed in the insert_filters
hook, and we put the chunk_filter in during ap_send_http_headers. This
time, the chunking filter is installed before the core_filter, and it
gets called correctly.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86089 13f79535-47bb-0310-9956-ffa450edef68
missing the needed comparison on the request. this allows subrequests to
insert filters properly (by stopping the scan before transitioning to
the parent request's filters)
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86085 13f79535-47bb-0310-9956-ffa450edef68
to the very bottom of the filter stack and nobody has written anything to
the network, then we need to return an error.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86062 13f79535-47bb-0310-9956-ffa450edef68
to add and modify data while processing a request. The docs still need
to be updated, and a simple html page needs to be created explaining all
of this.
The only filter currently in the code is the core filter. This filter
takes a bucket brigade and writes it to the network through the buff
structure. In time, the buff will go away completely.
More filters will need to be written.
Submitted by: The Apache Community
Reviewed by: The Apache Community
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@86059 13f79535-47bb-0310-9956-ffa450edef68
into the build. This warning will be removed automatically, as soon as
we decide on a prototype for the function causing the warning. That
decision is tied to which filtering mechanism we decide on.
Submitted by: Ryan Bloom and Greg Stein
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@85926 13f79535-47bb-0310-9956-ffa450edef68
