Skip to content
  1. Sep 27, 2018
  3. Sep 26, 2018
  5. Sep 23, 2018
  7. Sep 22, 2018
  9. Sep 21, 2018
  11. Sep 20, 2018
  13. Sep 18, 2018
  15. Sep 15, 2018
  17. Sep 13, 2018
  19. Sep 12, 2018
  21. Sep 11, 2018
  23. Sep 06, 2018
    • Yann Ylavic's avatar
      Follow up to r1840149: core input filter pending data. · a4b9355a
      Yann Ylavic authored 
      Since r1840149 ap_core_input_filter() can't use use f->[priv->]bb directly, so
ap_filter_input_pending() stopped accounting for its pending data.

But ap_core_input_filter() can't (and doesn't need to) setaside its socket
bucket, so ap_filter_setaside_brigade() is not an option. This commit adds
ap_filter_adopt_brigade() which simply moves the given buckets (brigade) into
f->priv->bb, and since this is not something to be done blindly (the buckets
need to have c->pool/bucket_alloc lifetime, which is the case in the core
filter) the function is not AP_DECLAREd/exported thus can be used in core only.

With ap_filter_adopt_brigade() and ap_filter_reinstate_brigade(), the core
input is now ap_filter_input_pending() friendly.

Also, ap_filter_recycle() is no more part of the API (AP_DECLARE removed too),
there really is no point to call it outside core code. MAJOR bumped once again
because of this.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1840265 13f79535-47bb-0310-9956-ffa450edef68
      a4b9355a
    • Eric Covener's avatar
      fix StrictHostCheck in single/non-NVH vhosts · 929df94d
      Eric Covener authored 
      While all VH'es are NVH'es in 2.4 and later, something special happens
once a second NVH in a set is added.  This case covers the 
global server config scenario as well.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1840229 13f79535-47bb-0310-9956-ffa450edef68
      929df94d
  25. Sep 05, 2018
  27. Sep 04, 2018
  29. Sep 03, 2018
    • Yann Ylavic's avatar
      core: always allocate filters (ap_filter_t) on f->c->pool. · b156c592
      Yann Ylavic authored 
      When filters are allocated on f->r->pool, they may be destroyed any time
underneath themselves which makes it hard for them to be passed the EOR and
forward it (*f can't be dereferenced anymore when the EOR is destroyed, thus
before request filters return).

On the util_filter side, it also makes it impossible to flush pending request
filters when they have set aside the EOR, since f->bb can't be accessed after
it's passed to the f->next.

So we always use f->c->pool to allocate filters and pending brigades, and to
avoid leaks with keepalive requests (long living connections handling multiple
requests), filters and brigades are recycled with a cleanup on f->r->pool.

Recycling is done (generically) with a spare data ring (void pointers), and a
filter(s) context struct is associated with the conn_rec to maintain the rings
by connection, that is:

    struct ap_filter_conn_ctx {
        struct ap_filter_ring *pending_input_filters;
        struct ap_filter_ring *pending_output_filters;

        struct ap_filter_spare_ring *spare_containers,
                                    *spare_brigades,
                                    *spare_filters,
                                    *spare_flushes;
        int flushing;
    };

MMN major bumped (again).


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