log either - or 0, before this patch, they were both logging
the file size.

PR:	8021
Submitted by:	Taketo Kabe <kabe@sra-tohoku.co.jp>


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

rather than on a per-character basis.  A significant amount of time
was spent checking the limit.  A better place to check for the threshold
is when we read the bucket in not as we read each character in the bucket.

If a bucket manages to be 200MB, it is not this code's problem as it
is a mere filter.

I ran this with the mod_include stuff in httpd-test and it looks good
from here.

Submitted by:	Brian Pane <bpane@pacbell.net>
Reviewed by:	Justin Erenkrantz, Ryan Bloom, Greg Stein, Cliff Woolley,
		Paul Reder, etc, etc, etc...


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

  After some consideration - Location walk is always required (before and
  after any other map_to_storage operations.)  Therefore, initialize any
  NULL r->per_dir_config at this phase (the earliest necessary point.)


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

  Finish a thought.  I'm hoping this drops the number of obnoxous requests
  to bugs for mime.types changes back down to mostly valid requests.


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

  I love it when a plan comes together.

  We hadn't prepared for this possibility that someone didn't set up the
  r->per_dir_config (which the subreq's didn't).  Since we are first in
  line, we will handle it if need be.


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

  Move ForceType/SetHandler from mod_mime to core, copy the Set*Filter
  description for Add*Filter in mod_mime, and cross reference them.


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

  Ahhh, a const headache.  Here's a flag that is writeable.


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

  Since we can preserve and further canonicalize the subreq_file name onto
  a canonical r->filename, let's do so.


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

  Add some notes of things I noticed while proofing.  We still need a
  resolution to rnew->chunked = r->chunked in subrequests!


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

  These no longer work, and even though most of this whole
  <IfModule mod_proxy.c> section doesn't work today, at least
  get the syntax right for <Proxy > blocks.


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

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

APR.  This should fix the build for BeOS.


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

Submitted by:	Ian Holsman <ianh@cnet.com>


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

  Can it be this simple?  No, probably not, but this fast-hack will get
  us going again for a while.

  We are currently rejecting some internal file_sub_req()'s in the
  translate phase.  I don't like this hack because of risks it potentially
  exposes, but for today, if we have a filename - and we are a subrequest,
  then let it fly without further mapping.  This allows us to serve up
  the default "/" request (run through mod_dir->mod_negotiation->mod_mime)
  without a 400 error.  The right solution is to set up some traps and
  escapes for the subreq mechanism, possibly with a subreq translate hook,
  and drop the URI entirely for these cases.


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

defined


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

This gets the build working on BeOS again :)  Apologies for the delay :(

Jeff changed the order of apr-util and apr to solve a "cleaning" issue but
that makes me uncomfortable as apr-util is dependant on apr, so if we clean
apr-util we shouldn't be altering anything in apr.  If I decide to rebuild
apr-util then apr should still be buildable.  Sorry Jeff but I think we need
a different solution :(

Submitted by:	Peter Schultz <pete@beforever.com>


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

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

----------------------------------------------------
if the base paths are the same
    if (strncmp(rnew->filename, fdir, fdirlen) == 0

and there's more stuff in the new filename than just the base path
        && rnew->filename[fdirlen]

and that stuff contains no slashes
        && ap_strchr_c(rnew->filename + fdirlen, '/') == NULL)
----------------------------------------------------

Assuming that's a correct translation, which I believe to be the case
(and which also seems to jive with the previous version of the test),
then that first part darned well better check == 0, as opposed to != 0.
strncmp returns 0 when they match.  =-)

And voila,
"All tests successful, 1 test skipped."
is the result from httpd-test


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

last tag, rather than UP to 2.0.26-dev.  =-)


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

  Now that stinks, sorry.  In moving code - I didn't notice my code
  now served out (r) info instead of the (rnew) info.  Made for nasty
  cyclic loops in mod_dir :(

  It looks like this works once again.  I'll post completed deltas to
  the list ASAP.


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

  Much better - sorry - I missed one case of forcing pipeline flush when
  the handler returned a non-OK result.  ergo, 304's weren't sent.


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

  Invoking the handler must occur at the caller's discression, in order
  for the sub_req mechanism to share this code.


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

  After calling ap_process_request_internal(), the caller must invoke
  the handler themselves.


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

  Move the ap_run_insert_filters to consistently occur in
  ap_process_request_internal.  This allows the sub_req handler
  to alter the filters before the subreq is actually run.


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

    Normalize all paths to run the same, common code for pre-request setup
    from the primary request, redirects and sub-requests.

    This will significantly reduce opporunities for inconsistancy (such
    as Ian observed, and as I repaired only a month ago.)

    This promotes process_request_internal to an ap_ namespace protected
    entity in server/request.c (from it's old home in http/http_request.c)
    since this fn has no http specifics.

Reviewed (in concept): Cliff Woolley, Ian Holsman


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

  Normalize all paths to run the same, common code for pre-request setup
  from the primary request, redirects and sub-requests.

  This will significantly reduce opporunities for inconsistancy (such
  as Ian observed, and as I repaired only a month ago.)

  This promotes process_request_internal to an ap_ namespace protected
  entity in server/request.c (from it's old home in http/http_request.c)
  since this fn has no http specifics.

Reviewed (in concept): Cliff Woolley, Ian Holsman


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

  The add-in/strip-off temporary trailing slash logic was really hosed
  in the new (not yet enabled) code path.  Now it's slightly hosed.


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

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

(which is the case with mod_proxy).

My only question about this is whether we should place some value
(such as <UNKNOWN>) when path_info isn't set.

Submitted by:	Ian Holsman <ianh@cnet.com>
Reviewed by:	Justin Erenkrantz


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

- Updates upgrading.html
- Reverts Aaron's earlier docco patch (sorry...)
- Adds -X to all mpms in the tree


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

  Fix the new code (not currently enabled) for directory_walk


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

mod_charset_lite checks to see if its filter will be
added by another module.  Now, we run our insert-filter
hook really last and look at the actual filter chain.

(Note that http runs even later but it doesn't currently
do anything which would interfere.)


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

  Undo another int type'ed port (and format a little structure for legibility).


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

  Fix a broken declaration (supress type conversion warning on win32).


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

to print the apr_status_t in numeric form

the old message

lt-httpd: could not open(create) scoreboard: Unknown resolver error

wasn't so useful, but the new, improved message

lt-httpd: could not open(create) scoreboard: (22528)Unknown resolver error

makes it look like a syscall is returning ENOSPC and that apr shmem
is returning (APR_OS_START_SYSERR + errno) instead of simply errno.

off to APR land...


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

  Same as Jeff Trawick's patch [thank you!] only a tad faster, and error
  out on the old Set{Input|Output}Filter onefilter twofilter syntax
  (prior to this patch, only the last filter in a space seperated list
  would be configured.)


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

we seem to be reading/seeking .var files fine on Unix even with
buffering turned on.

wrowe reports that they're working on Win32 also.


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

different format, mod_charset_lite needs different logic to walk
through it


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

tiny apr_pstrdup() calls and your machine crashes) when you
have a filter chain

  ap_getword() returns an empty string, not a NULL string,
  when there are no more words

fix a segfault when you don't have a filter chain

  ap_getword() does not check for a NULL string to search


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

  Thank you again for the proxy autobuild reports ;)


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