Re: mod_proxy_fcgi and flush

2017-07-13 Thread Yann Ylavic
On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano wrote: > > 1) read the FCGI headers to gather how much data the record is carrying > (clen) > 2) read the data in iobuf_size batches, sending each time the bytes > collected to the output filter chain. > 3) finally read the

Re: mod_proxy_fcgi and flush

2017-07-13 Thread Ruediger Pluem
On 07/13/2017 07:36 PM, Luca Toscano wrote: > I didn't find a real use case for flushpackets=auto in mod_proxy_fcgi, but I > have two proposals for fluspackets=on: > > http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch >

Re: mod_proxy_fcgi and flush

2017-07-13 Thread Luca Toscano
2017-07-10 11:42 GMT+02:00 Luca Toscano : > Hi Rüdiger, > > 2017-07-10 8:31 GMT+02:00 Plüm, Rüdiger, Vodafone Group < > ruediger.pl...@vodafone.com>: > >> >> >> >> >> *Von:* Luca Toscano [mailto:toscano.l...@gmail.com] >> *Gesendet:* Samstag, 8. Juli 2017 09:52 >> *An:*

CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

2017-07-13 Thread William A Rowe Jr
CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest Severity: Important Vendor: The Apache Software Foundation Versions Affected: all versions through 2.2.33 and 2.4.26 Description: The value placeholder in [Proxy-]Authorization headers of type 'Digest' was not initialized or

CVE-2017-9789: Read after free in mod_http2

2017-07-13 Thread William A Rowe Jr
CVE-2017-9789: Read after free in mod_http2 Severity: Important Vendor: The Apache Software Foundation Versions Affected: httpd 2.4.26 Description: When under stress, closing many connections, the HTTP/2 handling code would sometimes access memory after it has been freed, resulting in

Re: svn commit: r1801594 - in /httpd/httpd/trunk: docs/manual/mod/mod_proxy_wstunnel.xml modules/proxy/mod_proxy_wstunnel.c

2017-07-13 Thread jean-frederic clere
On 07/12/2017 07:25 PM, Jacob Champion wrote: > On 07/11/2017 05:36 AM, Yann Ylavic wrote: >> I think it's quite hazardous to use/allow ANY and would prefer the >> upgrade_method (worker->s->upgrade) to be a list of acceptable protocols. > > I think both ANY *and* NONE are dangerous. Both of them