Submitted by:	Hiten Pandya <hpandya@lycos.co.uk>


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

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

Place a big-ass comment there so that whomever comes next isn't stuck
at a cryptic call that they don't understand with a dinky comment.
Hopefully, this makes sense.  Someone more familiar with OpenSSL should
verify the comment.

This fix also requires the normalize call to be performed before
churn_input so that we don't enter churn_input with a 0-length ctx->b
brigade.

All httpd-test tests (except for the module/negotiation test) pass now.


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

we shouldn't delete it.

Thanks to Doug for pointing out that something broke.


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

Hey, I've never seen it in actual use anywhere, so I didn't know.

Thanks to Roy for pointing it out.


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

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

Tested with www.yahoo.com (Conn: Close), www.apache.org (CL), and
www.apple.com (TE: Chunked).


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

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

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

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

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

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

  Aye, it's bogus.  Something very odd about short terniary results on
  this C[++] compiler here, wants to promote to the conditition's type :-/


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

  Outch... fixed warning


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

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

that you can use this with CustomLog.


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

  Ok, this formats a whole lot cleaner, and (I believe) makes a bit more
  sense.  Also provides a rundown of C89 common date format strings, for
  those users who don't have man strftime [It still points out that add'l
  format options may b available, see strftime.]

  Also, I believe _most_ installations require the TransferLog "|bin/
  path to rotatelogs, no?  Other question - how to reformat to html?
  Which utility does so?


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

  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