Skip to content
  1. Jul 26, 2018
  3. Jul 25, 2018
  5. Jul 24, 2018
    • Yann Ylavic's avatar
      mod_proxy_http: forward 100-continue. · 5b92eb42
      Yann Ylavic authored 
      Handle end-to-end 100-continue, according to RFC 7231, such that the client
request body is not read/forwarded (according to its "Expect:" header) until
the backend wants to receive it (with interim 100 continue response), or never
forwarded if the backend provides a (non-interim) response and doesn't need
the client body at all.

This is achieved by filling the header_brigade in ap_proxy_http_prefetch()
and letting ap_proxy_http_request() determine whether it should forward that
brigade only (with the "Expect: 100-continue" specified by the client or added
according to "ping=" configuration), or forward the whole body for the usual
case (as before).

When 100-continue expectation is in place, the body is actually forwarded by
ap_proxy_http_process_response() when/if a "100 continue" response is sent by
the backend, otherwise the body is discarded; a future enhancement could make
so that in a balancer configuration, the body could be forwarded to another
balancer member depending on the status/error from the backend.

So stream_reqbody_cl() and stream_reqbody_chunked() functions are adapted to be
called by either ap_proxy_http_request() or ap_proxy_http_process_response(),
while spool_reqbody_cl() still spools the body in ap_proxy_http_prefetch() thus
before the backend is connected/reused to avoid inactivity on the connection
for the prefetch time (the prefetched body is also forwarded according to the
100-continue expectation, though).

Also, since the brigades and other runtime objects now need to be shared by the
ap_proxy_http_*() functions chain, a proxy_http_req_t struct/context is created
from the start and passed to them as (the single) argument. This is also a good
candidate for a future async baton, if we wanted to let the MPM event wait for
connection data for us at any stage and be called back ;)

Finally, ap_send_interim_response() is modified to correcly handle 100 continue
responses once, and take care of clearing r->expecting_100 only for them.

PR 60330.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836588 13f79535-47bb-0310-9956-ffa450edef68
      5b92eb42
    • Joe Orton's avatar
      * modules/ssl/ssl_engine_pphrase.c: Fix linking against OpenSSL without · a45c7956
      Joe Orton authored 
        ENGINE support.

PR: 62563


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1836547 13f79535-47bb-0310-9956-ffa450edef68
      a45c7956
  7. Jul 23, 2018
  9. Jul 20, 2018
  11. Jul 19, 2018
  13. Jul 18, 2018
  15. Jul 17, 2018
  17. Jul 16, 2018
  19. Jul 13, 2018
    • Yann Ylavic's avatar
      util_filter: follow up to r1835640: pending_filter_cleanup() precedence. · 93bab76a
      Yann Ylavic authored 
      Register pending_filter_cleanup() as a normal cleanup (not pre_cleanup) so
that the pending filters are still there on pool cleanup, and f->bb is set
to NULL where needed.

Then is_pending_filter() check is moved where relevant.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1835847 13f79535-47bb-0310-9956-ffa450edef68
      93bab76a
    • Yann Ylavic's avatar
      event: always favor APR_POLLSET_WAKEABLE over method/implementation. · b4f758c9
      Yann Ylavic authored 
      (probably more about correctness than a real issue since systems are
unlikely to implement more than one/their method...).


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1835846 13f79535-47bb-0310-9956-ffa450edef68
      b4f758c9
    • Yann Ylavic's avatar
      event, worker: runtime pool. · 3088f2b0
      Yann Ylavic authored 
      MPMs event and worker both need a dedicated pool to handle the creation of
the threads (listener, workers) and synchronization objects (queues, pollset,
mutexes...) in the start_threads() thread, with at least the lifetime of
the connections they handle, and thus survive pchild destruction (notably
in ONE_PROCCESS mode, but SIG_UNGRACEFUL is concerned too).

For instance, without this fix, the below backtrace can happen in ONE_PROCCESS
mode and a signal/^C is received (with active connections):

Thread 1 "httpd" received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  <BOOM>
#1  0x00007ffff7c7e016 in apr_file_write (thefile=0x0, ...)
                                          ^ NULL (cleared)
                       at file_io/unix/readwrite.c:230
#2  0x00007ffff7c7e4a7 in apr_file_putc (ch=1 '\001', thefile=0x0)
                                                      ^ NULL (cleared)
                       at file_io/unix/readwrite.c:377
#3  0x00007ffff7c8da4a in apr_pollset_wakeup (pollset=0x55555568b870)
                                              ^ already destroyed by pchild
                       at poll/unix/pollset.c:224
#4  0x00007ffff7fc16c7 in decrement_connection_count (cs_=0x7fff08000ea0)
                       at event.c:811
#5  0x00007ffff7c83e15 in run_cleanups (cref=0x7fffe4002b78)
                       at memory/unix/apr_pools.c:2672
#6  0x00007ffff7c82c2f in apr_pool_destroy (pool=0x7fffe4002b58)
                                            ^ master_conn
                       at memory/unix/apr_pools.c:1007
#7  0x00007ffff7c82c12 in apr_pool_destroy (pool=0x7fff08000c28)
                                            ^ ptrans
                       at memory/unix/apr_pools.c:1004
#8  0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555638698)
                                            ^ pconf
                       at memory/unix/apr_pools.c:1004
#9  0x00007ffff7c82c12 in apr_pool_destroy (pool=0x555555636688)
                                            ^ pglobal
                       at memory/unix/apr_pools.c:1004
#10 0x00005555555f4709 in ap_terminate ()
                       at unixd.c:522
#11 0x00007ffff6dbc8f1 in __run_exit_handlers (...)
                       at exit.c:108
#12 0x00007ffff6dbc9ea in __GI_exit (status=<optimized out>)
                       at exit.c:139
#13 0x00007ffff7fc1616 in clean_child_exit (code=0)
                       at event.c:774
                                  ^ pchild already destroyed here
#14 0x00007ffff7fc5ae4 in child_main (child_num_arg=0, child_bucket=0)
                       at event.c:2869
...


While at it, add comments about the lifetimes of MPMs pools and their objects,
and give each pool a tag (e.g. "pchild" accordingly to other MPMs).



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