Aaron Bannert [Thu, 7 Mar 2002 15:09:36 +0000 (15:09 +0000)]
It is bad to recursively remove every CVS directory in a person's
home directory. Bad bad bad. Make sure the variable was set to
something before cd-ing to blank and ending up in their $HOME.
Aaron Bannert [Thu, 7 Mar 2002 15:06:07 +0000 (15:06 +0000)]
It is bad to recursively remove every CVS directory in a person's
home directory. Bad bad bad. Make sure the variable was set to something
before cd-ing to blank and ending up in their $HOME.
Also, since each line under a make rule is treated as a new subshell,
it's not necessary to surround the whole line in ()s.
As hinted on dev@httpd, change filter naming schemes to match our
expectations of their usage.
The reason that we should make this change now is that we have changed
the implied meaning of AP_FTYPE_HTTP_HEADER - some users of this should
be PROTOCOL while others should be CONTENT_SET. In order to clarify it,
toss all of the bogus names and force the filter writers to make sure
they understand what they are doing.
CONTENT_SET is new (horrible name - change if you have better idea), but
it indicates that it should run between RESOURCE and PROTOCOL.
mod_deflate is the ideal CONTENT_SET filter.
The changed type names are:
CONTENT is now RESOURCE.
HTTP_HEADER is now PROTOCOL. However, most filters that used HTTP_HEADER
may want CONTENT_SET. (Only things like POP and HTTP belong as PROTOCOL.)
MMN bump since all filters need to be recompiled due to filter reordering.
Ryan Bloom [Thu, 7 Mar 2002 06:07:25 +0000 (06:07 +0000)]
We need to setup protocol filters for the fake request. If we don't,
then when any request filters are added, the connection filters will be
lost. This fixes the proxy.
Ryan Bloom [Thu, 7 Mar 2002 05:02:53 +0000 (05:02 +0000)]
There is no reason to insert the protocol filters in the insert_filters
phase. This moves us to inserting the filters in the create_request
phase. This makes more sense, because now the protocol filters are attached
to the request as soon as possible. Previously, some requests never
called the insert_filters phase, so they don't get the filters. Think
redirects for reqeusts that never call insert_filters.
Ryan Bloom [Thu, 7 Mar 2002 02:09:30 +0000 (02:09 +0000)]
Remove the prev pointer from the filter chain. This removes
the complexity of trying to set the filter chain correctly, with the
side-effect of forcing us to walk the entire chain whenever we add
a filter. Since the filter chains are small, the decrease in
complexity is worth it.
Reviewed by: Allan Edwards
Jeff Trawick [Thu, 7 Mar 2002 00:23:30 +0000 (00:23 +0000)]
64-bit build on AIX:
fix major bogosity in the logic to avoid setting LDR_CNTRL=MAXDATA=xxx
for a 64-bit build... the name of the environment variable was wrong
and even the test usage was bogus
Joshua Slive [Wed, 6 Mar 2002 15:57:52 +0000 (15:57 +0000)]
A few changes of my own:
Get rid of the 100% table widths, since they don't render well in MSIE.
Add the back in "Module Identifier".
Fix the remaining extra-space problems.
Cliff Woolley [Tue, 5 Mar 2002 18:21:39 +0000 (18:21 +0000)]
Detabify those parts of this file which don't collide with the bucket
freelist patch. The remaining tabs go away for free with that patch.
Submitted by: Sander Striker
Reviewed by: Brian Pane
Ryan Bloom [Tue, 5 Mar 2002 05:41:28 +0000 (05:41 +0000)]
Remove another hack from the server. The add_required_filters function
was required to make sure that the sub request had the correct filters
when we went send the error page. With the new filter insertion logic,
this is no longer necessary.
Bill Stoddard [Mon, 4 Mar 2002 17:13:08 +0000 (17:13 +0000)]
Bail on computing the amount of bytes in a brigade if any of the buckets
have indeterminate length (e.g., a pipe bucket). Passing an invalid length
into mod_mem_cache can cause it to overflow its cache buffer.
Ensure that net_time filter isn't added on subreqs - we assume that it is
added on !r->main requests. This led to infinite loop/SEGV when dealing
with anything that created a subreq.
(I don't think core_create_req is a good place for adding this filter.)
Ryan Bloom [Mon, 4 Mar 2002 05:54:44 +0000 (05:54 +0000)]
Adding the same filters over and over again used to be okay, because
we would lose the extra filters. Now, if a filter is added, it is run.
Unfortunately, this can cause an infinite loop, or it can cause request
headers to appear twice. This commit removes two instances in the core
where we were inserting filters for a second and third time. The bug
was that error responses were causing infinite loops.
This also removes the reset_filters function, which did the exact
same thing as add_required_filters. The two functions were both called
in error conditions, which was part of what caused this bug.
Ryan Bloom [Mon, 4 Mar 2002 05:29:04 +0000 (05:29 +0000)]
If we insert a protocol filter before we insert a request filter, we
must set the r->output_filter to r->proto_output_filter. If we don't,
then as soon as we insert the request filter, the protocol filter will
be removed. This was causing headers to not be sent on some requests.
Ryan Bloom [Sun, 3 Mar 2002 22:34:55 +0000 (22:34 +0000)]
Classify some of the input filters as the correct types. Previous to
this patch, the type wasn't too important, because all filters were
put on the same list. After this patch, the filter type is very important,
because there are three different types of filters, and they are all treated
differently, namely:
CONNECTION: Filters of this type are valid for the lifetime of this
connection.
PROTOCOL: Filters of this type are valid for the lifetime of this
request from the point of view of the client, this means
that the request is valid from the time that the request
is sent until the time that the response is received.
CONTENT: Filters of this type are valid for the time that this
content is used to satisfy a request. For simple requests,
this is identical to PROTOCOL, but internal redirects
and sub-requests can change the content without ending
the request.
It is important to realize that the three major types above are actually
broken down into smaller groups in the code, to ensure that the ordering
of filters is always correct.
Ryan Bloom [Sun, 3 Mar 2002 22:04:03 +0000 (22:04 +0000)]
This fixes most of the header bug that was committed last night. The server
is seg faulting on pipelined requests currently, but I want to get people
back to a running server.
Ryan Bloom [Sun, 3 Mar 2002 06:04:08 +0000 (06:04 +0000)]
This finishes the mod_dir/mod_negotiation bug. This final part of the
solution ensures that we don't lose filters if they are added later than
we expect. The problem could be seen if a connection filter was added
after a request-based filter was added in the past. The problem was that
the request-based filters pointed to the first filter in the connection
record, so the new connection filter was never called. Now, all filters
are put on their correct filter lists, and we are sure to always update
all pointers when adding a filter.
Ryan Bloom [Sun, 3 Mar 2002 02:15:52 +0000 (02:15 +0000)]
Fix the mod_dir/mod_negotiation bug, where redirects and sub requests
were not getting the correct filters. This is done by creating a location
in the request rec that holds protocol level filters. Protocol level
filters survive for one request, from the time the request is received
from the user to the time the response is sent. r->output_filters now
stores the request level filters, which are only valid for the lifetime
of one request_rec.
This patch works, but it is not complete. The second half of the problem
is that add_any_filter doesn't check where it puts the filters that it
adds, so it is possible for filters to be put on this wrong list, and
for filters to be lost completely during request processing. That half
of the fix will be coming in the next day or so.
Submitted by: Will Rowe, Justin Erenkrantz, Ryan Bloom
Doug MacEachern [Sun, 3 Mar 2002 00:46:07 +0000 (00:46 +0000)]
reuse existing private key if possible for all SSLPassPhraseDialog
types, not just builtin. on win32 for example, a pipe dialog might
allocate a wintty for prompting, which results in 4 prompts at
startup, 2 for each child and 2 within each when httpd "restarts
itself".
update comments on this and wrap them a bit.
Rich Bowen [Sat, 2 Mar 2002 02:37:17 +0000 (02:37 +0000)]
Added example of denying, or allowing, particular users to have UserDir
directories.
In a discussion on IRC, it was requested that an explicit example of
this configuration be provided in the documentation.
next_filter of NULL to any ap_sub_req_lookup*() fn implies the subreq
will never be run - or we expect to pass the subreq to fast_redirect.
The comming fix will break invalid ap_sub_req_lookups* expecting to
run subrequests with the next_filter NULL semantic.
Significant cleanup and enable wintty to -always- escape from the service
context when the run-as-user is LocalSystem or has access to the windows
station and desktop. The original method did not give us a visible tty
unless the 'Allow Service to Interact with Desktop' toggle was set.
Cliff Woolley [Fri, 1 Mar 2002 05:43:57 +0000 (05:43 +0000)]
We don't need transfer_brigade() because we already have macros to do that
for us, and faster. :)
Warning, though: transfer_brigade() was equivalent to APR_BRIGADE_CONCAT(),
and I don't think that was the right behavior for one of the two callers!
I changed that one to use APR_BRIGADE_PREPEND() since by my inspection that
looks like what it should be, but please check me on this.
projects / apache / log