Skip to content
  1. Dec 19, 2006
    • Ruediger Pluem's avatar
      * Vote and promote · 4e17519f
      Ruediger Pluem authored 
      
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488853 13f79535-47bb-0310-9956-ffa450edef68
      4e17519f
    • William A. Rowe Jr's avatar
      one more vote twords an actual patch - note this is tested in production · 7d750fda
      William A. Rowe Jr authored 
      by several on the bug thread.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488835 13f79535-47bb-0310-9956-ffa450edef68
      7d750fda
    • Ruediger Pluem's avatar
      Merge r484978,r484787,r484792 from trunk: · 8013d502
      Ruediger Pluem authored 
      * Isolate the unlock return vals

* Log when the lock fails.

* Failure to unlock is very nasty, so log it to help with troubleshooting.

Submitted by: jim
Reviewed by: jim, rpluem, wrowe


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488822 13f79535-47bb-0310-9956-ffa450edef68
      8013d502
    • Ruediger Pluem's avatar
      * This proposal has been backported · 41936f78
      Ruediger Pluem authored 
      
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488818 13f79535-47bb-0310-9956-ffa450edef68
      41936f78
    • Ruediger Pluem's avatar
      Merge r422731, r422736, r422739, r423940, r424759, r424950, r425109, r426790, · 3bf3f92a
      Ruediger Pluem authored 
      r426791, r426793, r426795, r416165, r426799, r475403, r475406, r475915,
r475920, r475922, r476600, r437668 from trunk, which makes mod_deflate.c the
same as r483597 from trunk:

All comments to these changes for the sake of completeness:

* Fix wrong FLUSH bucket handling in deflate_out_filter: Actually the internal
  structures of libz never got flushed as ctx->stream.avail_in is always zero
  here. As the EOS and the FLUSH bucket case use the same code for flushing
  libz's internal buffers move this code to the new function flush_zlib_buffer.

* Fix potential memory leaks in deflate_out_filter if bailing out due to an
  error (either in the lower filter chain or during a libz operation). We need
  to call deflateEnd as it is very likely that this filter is never called
  again to ensures that libz's internal structures get cleaned properly.

* Remove ourselves from the filter chain if we failed to init libz, as we
  pass data down the filter chain uncompressed afterwards.

* In preparation of the changes of the inflate out filter:
  - rename flush_zlib_buffer to flush_libz_buffer (this name seems
    better)
  - add a parameter to tell flush_libz_buffer whether it should
    deflate or inflate as this function should be also used for the
    inflate out filter.

* This shortcut is too short. It is not up to the filters to decide
  whether filters down the chain can do something useful with this empty
  brigade.

* Initialize zRC to avoid a compiler warning.

* Rather use a pool cleanup function than calling deflateEnd before every
  return from function to ensure that libz's internals get cleaned up.

* Add parameter crc to flush_libz_buffer in order to call the libz's crc32
  function on the output buffer if needed. This is actually needed by the
  later rework of the inflate out filter.

* Use a define for the number of validation bytes (CRC and length) after the
  compressed data

* We can ignore Z_BUF_ERROR in flush_libz_buffer because:
  When we call libz_func we can assume that

   - avail_in is zero (due to the surrounding code that calls
     flush_libz_buffer)
   - avail_out is non zero due to the fact that we just emptied
     the output buffer and stored it into a brigade

  So the only reason for Z_BUF_ERROR is that the internal libz
  buffers are now empty and thus we called libz_func one time
  too often. This does not hurt. It simply says that we are done.

* some optimizations taken from the inflate out filter

* Remove bogus code that chokes on flush buckets

* Rework inflate out filter and give it a similar workflow as the deflate out
  filter. This fixes the following bugs in the inflate out filter:

  - Incorrect handling of flush buckets.
  - Excessive memory usage for large compressed content (because we now
    already sent parts down the chain and do not process the whole brigade
    first before sending something down the chain).
  - Handle the case correctly where the validation bytes at the end of
    the compressed data stream are distributed across different buckets /
    brigades.
  - Fix a memory leak due to not cleaning up the internal structures of
    libz in some error cases.

* Ensure that we do not try to inflate validation data or garbage data. None
  of this is zlib's business.

* Ensure that we do not perform our final operations twice if a second EOS
  falls down the chain by accident. Otherwise we are likely to run in a
  SEGFAULT. So remove ourselves from the chain.

* Actually append new data to the validation buffer and do not overwrite old
  data already there by setting the correct offset for the target buffer.

* Also log the presence of garbage data at the end of the stream if all
  validation data is available in the first round.

* Housekeeping: keep track of size even in the edge-case where validation
  bytes trickle in over multiple buckets.


PR: 39854
Reviewed by: rpluem, niq, jerenkrantz, wrowe


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488817 13f79535-47bb-0310-9956-ffa450edef68
      3bf3f92a
    • William A. Rowe Jr's avatar
      Votes and Notes; the first four I would like to see applied before · c19336d7
      William A. Rowe Jr authored 
      tagging 1.2.4; add a better patch for the winnt mpm wait patch
that makes this reviewable (sometimes -U3 just isn't enough context.)


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488780 13f79535-47bb-0310-9956-ffa450edef68
      c19336d7
    • Justin Erenkrantz's avatar
      Approve two backports · fb3a9b58
      Justin Erenkrantz authored 
      
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@488516 13f79535-47bb-0310-9956-ffa450edef68
      fb3a9b58
  3. Dec 18, 2006
  5. Dec 17, 2006
  7. Dec 16, 2006
  9. Dec 15, 2006
  11. Dec 14, 2006
  13. Dec 13, 2006
  15. Dec 12, 2006
  17. Dec 11, 2006
  19. Dec 10, 2006
  21. Dec 09, 2006
  23. Dec 08, 2006