Some funkyness remains with Win32 telnet doing folding - that can wait til
tomorrow.


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

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

Submitted by:	Pier P. Fumagalli <pier@apache.org>


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

at least now we are serving SHTML files again.
PR:	6641


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

or we'll seg-fault.  This should set the sub-request's request_config
structure to the same exact same structure as the main request is using.


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

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

BUFF.  This doesn't actually change any behavior, it just makes the core
access socket directly.


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

with this.  To begin with, we store both the socket and the BUFF in the
conn_rec.  Functions are free to use which ever they want, in the end all
of the data goes to the same place.  This modifies all of the MPMs except
Windows.  All of the Unix MPMs are working, but the others need to be
tested.


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

redirects.  If this isn't done, we'll seg-fault during the AP_DEBUG_ASSERT
that makes sure getline didn't leave any droppings.


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

PR:	6653
Submitted by:	 Tomas "�gren" <stric@ing.umu.se>
Reviewed by:	 Ryan Bloom


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

  That's the end of things broken this morning... now to try Jeff's patch


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

instead of a brigade in core_dir_conf.  For now, getline() and
ap_get_client_block() share a brigade.


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

  Fix more broken things


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

  Fix a broken thing


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

  expatlib is definately more in sync with the Unix build, so we now
  build the expatlib.dsp rather than seperate xmltok/xmlparse .dsp's.

Submitted by:	Greg Stein
Reviewed by:	William Rowe


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

no \n at the end of it.  This was caused by apr_fgets returning
APR_EOF even though we had read valid data.  This is solved by
making cfg_getline check the buff that was returned from apr_fgets.
If apr_fgets return APR_EOF, but there was data in the buf, then we
return the buf, otherwise we return NULL.


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

that lives across function calls during a single request.  Change getline() to
take a request_rec parm (rather than a conn_rec) so we can access the
core_request_config.

This is in preparation for adding look-ahead functionality to getline(), so it
can support header line folding once again.  I'm committing these changes first
so the core_request_config can be used elsewhere (i.e. ap_get_client_block).


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

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

1) cleans up an annoying type that was getting in my way while I was
   trying to fix things.
2) Makes some of the allocations pcalloc instead of palloc
3) The arg array passed to create_process is a const *char *, not
   const *char [].
PR:     6642


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

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

rewrite map lookup keys and default values are now expanded
so that the lookup can depend on the requested URI etc.

Because the new code is recursive you can now write configurations
like the following (with nested map lookups) which wasn't directly
possible before -- you had to use a RewriteCond and a %N backref
instead, as in http://www.apache.org/docs/vhosts/mass.html#xtra-conf

RewriteMap tolower int:tolower
RewriteMap host2user txt:/home/www/conf/virtusertbl
RewriteRule /(.*) /home/${host2user:${tolower:%{HTTP_HOST}}|www}/public_html

PR: 6671


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

security bug in some mass virtual hosting configurations
that can allow a remote attacker to retrieve some files
on the system that should be inaccessible. The problem
occured with requests including the line "Host: ..." --
the last dot is stripped and the remaining ".." then
reveals a parent directory.

Reported by: Peter Christoffersen <pch@mindpass.com>
Message-ID: <8quts6$2el$1@news.inet.tele.dk>
Newsgroups: comp.infosystems.www.servers.unix


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

the buffer_filter, and where the core_filter gets data from the BUFF.


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

used although I have begun to test them on my machine.  The idea behind
these buckets is that data allocated out of a pool and put into a bucket
has to survive the death of the pool until the bucket is destroyed.  To
accomplish this, we register a cleanup when we create the bucket.  If the
pool is cleared, the cleanup converts the bucket to a heap bucket and
everything is good.  If the pool isn't cleared, then we kill the cleanup
when the bucket is destroyed.

With this bucket type, all of the core buckets that were listed have been
implemented.


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

before today) so that we don't have a growth of these across many
pipelined requests.

http_filter() uses one brigade per connection which it reads into.
As it needs to deliver buckets to the caller, they are removed from
its brigade into the caller's brigade.

Submitted by:	Ryan Bloom (but anything broken is my fault)


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

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

  get rid of an unnecessary condition where we set ctx->b to NULL;
  it was already NULL

ap_get_client_block():
  "fix" the pool for the brigade used by ap_get_client_block() to
  save its state; this allows pipelined requests to work


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

if we drop one on the floor, it will get cleaned up when we clean the pool.


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

  when delivering body bytes, only deliver one block of data (however
  much is returned by bucket read) instead of delivering the entire
  body at once; this gets painful with a large body

  make a note of an issue with the blocking state of the socket;
  currently, the socket is non-blocking, but when reading body bytes
  we should feel free to wait for body bytes until a timeout occurs;


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

it makes sense logically.


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

  Make things a little clearer in reaction to the _snames snafus.

Submitted by:	Greg Stein
Reviewed by:	William Rowe


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

"output_filters" for consistency with the name of the input
filters field ("input_filters").


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

This should have been committed with httpd.h a few minutes ago.
Submitted by:	Greg Stein


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

if their forbearers (e.g., ap_assert()) did not.
Submitted by:	Greg Stein


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

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

they are currently storing.  There is no way we can force them to flush,
but we can advise.  This also adds the code to ap_rflush to use flush
buckets, although it isn't enabled yet.  I will enable it once we remove
buff from the code.  I also removed all calls to ap_rflush that are either
immediately before or immediately after a call to ap_finalize_protocol.
ap_finalize_protocol sends an EOS bucket, which also advises filters to
flush their data, so having both calls right next to each other is
redundant.


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

brigade generated by the sub-request.  If this is not done, then the
main-request's core_output_filter will get very confused, as will any other
filter in the main-request filter-stack that looks for EOS.


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

(hopefully) be easier to understand in the future.


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

  Get rid of an assertion which assumed that HTTP_IN is the filter
  below us.  Some other filter may play the same role.
ap_setup_client_block():
  Get rid of a commented-out hack which was used to allow chunked
  transport encoding of a request body received by mod_cgi[d].
ap_get_client_block():
  Get rid of special handling for zero-length buckets...  The main
  loop handles that fine.
Submitted by:	Ryan Bloom


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

  get dechunking working
  verify that infrastructure for input filters works
    (use existing AddInputFilter directive)

Unlike with my previous patch, ap_get_client_block() saves state between
calls in the core's per-request dir config.

Unlike with my previous patch, HTTP_IN keeps a count of remaining bytes
in the conn_rec.  Code that needs to prod it to deliver a certain amount
of request body plays with conn_rec->remain directly.


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