I was too stupid to read the code to determine that the accept mutex
failure log messages were harmless and not indicative of a real problem.

I'll try to understand the conditions where I'm seeing connections
dropped.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93721 13f79535-47bb-0310-9956-ffa450edef68

about the log level and use APLOG_DEBUG if we're restarting


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93720 13f79535-47bb-0310-9956-ffa450edef68

failed when actually it was apr_proc_mutex_unlock() which failed


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93719 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93718 13f79535-47bb-0310-9956-ffa450edef68

(de-tab)
PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93717 13f79535-47bb-0310-9956-ffa450edef68

PR:
Obtained from:
Submitted by:
Reviewed by:


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93716 13f79535-47bb-0310-9956-ffa450edef68

file from the template


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93715 13f79535-47bb-0310-9956-ffa450edef68

freelist patch.  The remaining tabs go away for free with that patch.
Submitted by:	Sander Striker
Reviewed by:	Brian Pane


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93714 13f79535-47bb-0310-9956-ffa450edef68

also, eradicate a few nefarious tabs which were found lurking in the vicinity.

Submitted by:  Rob Simonson <simo@us.ibm.com>
Reviewed by:   Greg Ames


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93711 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93710 13f79535-47bb-0310-9956-ffa450edef68

protocol filters.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93709 13f79535-47bb-0310-9956-ffa450edef68

list is over.  Do not stop if the next filter is NULL.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93708 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93706 13f79535-47bb-0310-9956-ffa450edef68

This has been a FAQ with some new 2.0 module developers.

Submitted by:	Thom May <thom@planetarytramp.net>
Reviewed by:	Aaron Bannert


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93705 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93703 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93702 13f79535-47bb-0310-9956-ffa450edef68

I'm termporarily holding off committing the html transformations while
we work out a few stylesheet problems.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93701 13f79535-47bb-0310-9956-ffa450edef68

  Just formatting cleanup, nothing interesting here, move along :)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93700 13f79535-47bb-0310-9956-ffa450edef68

Even though I can hit it pretty readily on my Linux box,
I can't reproduce on AIX or Solaris and I don't think anybody
else noticed it on Linux.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93699 13f79535-47bb-0310-9956-ffa450edef68

have indeterminate length (e.g., a pipe bucket). Passing an invalid length
into mod_mem_cache can cause it to overflow its cache buffer.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93698 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93697 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93696 13f79535-47bb-0310-9956-ffa450edef68

(Justin took a minor pass at this on top of Sander's patch.)

Submitted by:	Sander Striker <striker@apache.org>
Reviewed by:	Justin Erenkrantz


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93695 13f79535-47bb-0310-9956-ffa450edef68

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.)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93694 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93693 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93692 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93691 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93690 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93689 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93688 13f79535-47bb-0310-9956-ffa450edef68

return the correct information.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93687 13f79535-47bb-0310-9956-ffa450edef68

is seg faulting on pipelined requests currently, but I want to get people
back to a running server.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93686 13f79535-47bb-0310-9956-ffa450edef68

- Add a facility for translations.
- Add a type="warning" for <note>.
- Clean up some variable definitions.

Submitted by:  Patrik Grip-Jansson <patrikj@gnulix.org>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93685 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93684 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93683 13f79535-47bb-0310-9956-ffa450edef68

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


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93682 13f79535-47bb-0310-9956-ffa450edef68

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.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93679 13f79535-47bb-0310-9956-ffa450edef68

the bucket api gets changed.)

Submitted by: Brian Pane


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93678 13f79535-47bb-0310-9956-ffa450edef68

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93676 13f79535-47bb-0310-9956-ffa450edef68

<notes>. Other minor cleanup.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@93673 13f79535-47bb-0310-9956-ffa450edef68