Close the mod_mime file extension matching issue by (as Ken Coar suggests)
  allowing users to continue to rely on the old 1.3 behavior of matching Any
  extensions, the strict behavior of matching NegotiatedOnly arguments, or
  including Handlers and Filters with the MultiviewsMatch directive for
  mod_negotiation control.  Unfortunately, the component matching occurs
  in mod_mime, so that's where this option must reside.


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

but we documented it as --enable-mod-shared.


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

type for the length than the brigade functions do.  This moves the
len_read variable into the correct scope for the two times that it
is used, and defines it correctly for each scope.


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

the default httpd.conf for any module that was compiled
as a DSO.

Submitted by:	Aaron Bannert <aaron@clove.org>


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

changed some of the style issues within the filtering code to conform to
the rest of the server.

Various incarnations of this patch have been posted to dev@httpd without
feedback.  Now that it passes all of the httpd-test cases (with the
exception of module/negotiation test which fails without mod_ssl anyway),
it is time to check it in.

Please review and test.  We are under C-T-R rules, so I'm going to take
advantage of that and commit it now.  I have tested this about as much
as I can and it seems to work from everything I can give to it.
Considering that mod_ssl was broken before this commit, this is an
improvement.


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

be how many bytes we read.  This trounces on the r->remaining value, so
we must use a local variable and subtract that from r->remaining after we
read.
Reviewed by:	Aaron Bannert


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

of our brigade - which are in isolation okay.  In this situation, they
must be removed by the call to APR_BRIGADE_NORMALIZE.

The way we partition the buckets means that we will never remove the
zero-length bucket from the head - causing an infinite loop.  We read only
a single bucket now - previously partition with the blocking reads would
read multiple buckets - but it forced having a defined length which we
agreed was bogus.

Therefore, if we have a zero-length bucket at the head, we would then try
to partition and split at the zero-point of the brigade.  That combination
doesn't actually remove the zero-length bucket - it is still there - causing
an infinite loop because we'll never go past the zero-length bucket.

This call was originally present in core_input_filter.  I think it might
be better to fix partition/split/etc to eliminate a zero-length bucket
and skip it.  But, I'm not 100% sure that needs to happen.


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

a bucket.


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

executable, not "httpd".


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

  Finish the switch to huge file support


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

  Support huge files from mod_asis


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

  Negotiation once allowed any file, of any filename extension, to be
  served.  The original patch to mod_negotation eliminated all extensions
  that did not reflect filename extensions associated with negotiation
  variables, unless the user expressly specified the file name with those
  filename extensions.

  This patch [attributed to me] was vetoed at its inception, it was provided
  as an alternative for those who had to have the current behavior.

  There is now another alternative patch that would introduce the
  MultiviewsMatch directive to mod_mime, for consideration and discussion.


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

If the status code is anything other than SUCCESS for PEEK, it isn't
good.  Just return the value.

(I thought it should be this, but I wasn't 100% sure.  Peer review == good.)

Submitted by:	Will Rowe


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

Return with APR_EOF if we get EAGAIN.

(Whomever is calling this with PEEK should really be able to handle EOS
 bucket rather than relying on error codes.)

Thanks to Greg Ames for pointing out this fubar.


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

  Catch up to Martin's work for 2.0


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

  Short of removing the headers filter, this is the best asis can do.
  Note that all body replies were entirely broken (thanks for helping
  me notice this, Greg :)

  Asis still needs patching for huge files.


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

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

not all of the configured ports.

Other points to ponder:

  why no log message for the segfault?

  similar change would seem to be needed in other MPMs...  we
  may be adding bogus entries to the poll set


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

  Too many args is a bad thing too, some days


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

  Rewrite of rotatelogs as an apr-ized app.

  Mladen Turk <mturk@mappingsoft.com>, William Rowe


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

  Correct dependency for apr-ization of rotatelogs


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

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

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

core are requested.

If you want to disable shared library support, pass --disable-so to
configure (as always).  This will enforce that your httpd can NOT use
shared libraries - which may be a good thing for you to do.

Justin added the APR_HAS_DSO check per discussion on-list between Aaron,
Ryan, Greg, and the rest of the peanut gallery.  This should allow us
to not build mod_so when it isn't supported.  However, the rest of the
configure scripts need to know that shared objects aren't supported and
complain accordingly.  (sharedobjs = yes, error out?)

Submitted by:	Aaron Bannert <aaron@clove.org>
Reviewed by:	Justin Erenkrantz


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

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

Submitted by:	Hartmut Obendorf <obendorf@informatik.uni-hamburg.de>


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

  Always helps to add the member


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

  Bring many things up-to-date.  FirstBill, wasn't the child logging
  process stuff already fixed?


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

  Speed it up.  While this optimization wasn't obvious for the two-pass
  location_walk, it is significant for all subreq/redirects reusing the
  cached walk values.


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

  Uhmm... time for a note about this.


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

AddOutputFilter to be ignored when matching the URI.

Submitted by:	Bill Rowe


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

This can happen if there is a partial match between a bad URI and a
file with a variant extention.

ap_sub_req_lookup_dirent has apparently been generating bogus subrequest
URIs for ages, but they used to be ignored.  Once we started calling
ap_process_request_internal for all subrequests, they started causing
problems.  Make it explicit that rnew->uri is to be ignored for this type
of subrequest.


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

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

time, error level, etc strings.  The only information in the string is
the actual error.
Submitted by:	Jon Travis <jtravis@covalent.net>


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

line, thinking we've set a custom status. Of course, it says "200 OK" no
matter what error we happen to return(!).


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

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

add HTTP_IN filter after the headers have been parsed.
so that the HTTP_IN can check them ;-)
Still not 100% if this works properly, but I don't get
the chunking numbers displayed on my browser,
so it's better than what was there.
PR:
Obtained from:
Submitted by:
Reviewed by:


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

everything else happy as well)


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

check_pipeline_flush(), making it think another request was available (when
it wasn't). Apache would avoid flushing the prior request and block on
reading the next request. (of course, the client wasn't sending the next
one, cuz it was still waiting for the results of the first one)


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

Status: It serves a reverse-proxy page.. but SLOWLY.
VERY SLOWLY.
still looking at why, but now it serves pages instead of dumping core.
PR:
Obtained from:
Submitted by:
Reviewed by:


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