before that could still be buffered in the network filter. This is the case
  if we have sent an EOS bucket or if we actually sent buckets with
  data down the chain. In all other cases we either have not sent any
  buckets at all down the chain or we only sent meta buckets that are
  not EOS buckets down the chain. The only meta bucket that remains in
  this case is the flush bucket which would have removed all possibly
  buffered buckets in the network filter.
  If we sent a flush bucket in the case where not ANY buckets were
  sent down the chain, we break error handling which happens AFTER us.


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

OPENSSL's LICENSE after the AL in LICENSE.


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

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

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

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

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

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

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

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

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

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

  network filters get flushed to the network. This is needed since
  these buckets have been created with the bucket allocator of the
  backend connection. This allocator either gets destroyed if
  conn->close is set or the worker address is not reusable which
  causes the connection to the backend to be closed or it will be used
  again by another frontend connection that wants to recycle the
  backend connection.
  In this case we could run into nasty race conditions (e.g. if the
  next user of the backend connection destroys the allocator before we
  sent the buckets to the network).

  Remark 1: Doing a setaside does not help here as the buckets remain
  created by the wrong allocator in this case.

  Remark 2: Yes, this creates a possible performance penalty in the case
  of pipelined requests as we may send only a small amount of data over
  the wire.


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

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

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

Pointed out by: Takashi Sato <serai lans-tv.com>


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

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

  it was needed to register connection_cleanup as a cleanup for the frontend
  connection memory pool (c->pool) to ensure that connection returns into the
  connection pool if the memory pool of the frontend connection memory pool
  gets destroyed / cleared. Now we ensure explicitly the connection returns
  to the connection pool once we finished handling the request.


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

  data structure alive in the reslist, the live time of c->pool is too long.
  r->pool has the correct live time since rp dies before r.


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

This has no security impact since the browser cannot be tricked
into sending arbitrary method strings.

(words from jorton)


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

* modules/mappers/mod_imagemap.c (menu_header): Fix
  cross-site-scripting issue by escaping the URI, and ensure that a
  charset parameter is sent in the content-type to prevent
  autodetection by broken browsers.

Reported by: JPCERT


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

installer.  This will permit the installation tool to remove
all running instances before attempting to remove the .exe.

Note that since the introduction of CriticalSections, our
compatibility with NT 4 was destroyed, and at this point that
is no loss (there are no more security updates to NT 4 ergo
it's not an OS we want connected to the internet, anyways).
The WTS api calls require 2000 or later, but I'm not wrapping
them since nobody notices the same issue with CriticalSections.

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

  member of the proxy_conn_rec struct as we destroy this data more frequently
  than other data in the proxy_conn_rec struct like hostname and addr (at least
  in the case where we have keepalive connections that timed out and were
  closed by the backend).
  This fixes a memory leak with short lived and broken connections.

PR: 44026


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

  time) but empty it (via APR_BRIGADE_PREPEND) and reuse it. 

Submitted by: Stefan Fritsch <sf sfritsch.de>
Reviewed by: rpluem


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

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

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

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

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

PR: 23567
Submitted by: Stefan Fritsch <sf sfritsch.de>
Reviewed by: rpluem


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

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

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

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

* modules/http/http_filters.c
  (ap_http_filter): Put case on its own line.


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

  Basicly the persistence is created by keeping the conn_rec structure
  created for our backend connection (whether http or https) in the connection
  pool. This required to adjust scoreboard.c in a way that its functions can
  properly deal with a NULL scoreboard handle by ignoring the call or returning
  an error code.


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

  by jim. No functional change.


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

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

termination is completely unneeded and superflous. In
which case, the original allocation size is sufficient
since nothing external worries about a NULL nor
looks for it.


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

  * Precreate all needed brigades, save them in the filter context and reuse
    them in order to avoid frequent recreations using the request pool.

  * Use a temporary pool for all the needed copy stuff and clean it up every
    time we passed the passbb brigade down the chain. We can pass the
    brigade down the chain directly after we processed one bucket from the
    original brigade as buffering is done by the network filters.

  * Use transient instead of pool buckets.

  * There are cases that lead to the exceptional situation of a very large
    passbb bucket brigade (about 1,000,000 buckets) as a result of processing
    4 MB of a file. So I add a flush bucket once I have more than
    MAX_BUCKET (1000) buckets in the brigade and pass it down the chain to get
    it send and the passbb bucket brigade cleaned up and its memory reusable
    again.



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

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

  BODY_CHUNK_PART state like we do several lines later in the code in the
  same situation.


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

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