[Patch] Ensure HTTP1 filters are only added on HTTP1 requests

Hi all, The following patch fixes the problem where the HTTP1 filters are added on non HTTP1 requests. The filters are now only added if ap_get_protocol() returns AP_PROTOCOL_HTTP1. Regards, Graham -- Index: modules/http/http_core.c

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 14 Mar 2016, at 10:48 AM, Ruediger Pluem wrote: > This seems to cause frequent (no always) failures with test 8 of > t/ssl/proxy.t. > The request times out with a 504 status. So it looks like the "backend" in > this request does not respond. > Used MPM is Event, OS CentOS

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On 14 Mar 2016, at 11:13 AM, Stefan Eissing wrote: > Like the direction this is going as well. > > Do we need a MPM Query for detecting support before one actually has a handle > for registration? We do - most recent patch has that, and we managed to drop one

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On 14 Mar 2016, at 11:17 PM, Yann Ylavic wrote : >> Having looked at this in more detail this isn’t as simple. >> >> The sticking point is the cleanup, which needs to be passed a single struct >> to do it’s work. To pass both the pfds and the npdfs these two need to be >>

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On Mon, Mar 14, 2016 at 8:51 PM, Graham Leggett wrote: > On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote: > >> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could >> remove the indirection here (and in the code below) with somthing like

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote: > Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could > remove the indirection here (and in the code below) with somthing like > (apr_pollfd_t *pfds, size_t npfds, ...). > That would allow a single

Re: apache-swat project - need feedback!

I have just update some docs on swatpm.org to help beginners start with swat on more gentle way: - http://swatpm.org/ - hello world example to start with - http://swatpm.org/faq - FAQ page with answers to possible common questions about swat Regards PS anyway, if anybody succeeded in starting

Re: svn commit: r1734947 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/http_core.h server/core.c server/util_script.c

Feedback requested below on a couple of issues... On Mon, Mar 14, 2016 at 11:42 AM, wrote: > Author: trawick > Date: Mon Mar 14 15:42:45 2016 > New Revision: 1734947 > > URL: http://svn.apache.org/viewvc?rev=1734947=rev > Log: > Add CGIVar directive for configuring

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

They are also proxy-timeout related it seems: # testing : QUERY_STRING passed OK # expected: qr/QUERY_STRING = horse=trigger\n/s # received: ' # # 504 Proxy Error # # Proxy Error # The gateway did not receive a timely response # from the upstream server or application. # ' not ok 27 # Failed

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 03/14/2016 02:55 PM, Jim Jagielski wrote: > >> On Mar 14, 2016, at 4:48 AM, Ruediger Pluem wrote: >> >> >> This seems to cause frequent (no always) failures with test 8 of >> t/ssl/proxy.t. >> The request times out with a 504 status. So it looks like the "backend" in >>

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

> On Mar 14, 2016, at 7:07 AM, Graham Leggett wrote: > > On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote: > >> Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could >> remove the indirection here (and in the code below) with somthing

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

> On Mar 14, 2016, at 4:48 AM, Ruediger Pluem wrote: > > > This seems to cause frequent (no always) failures with test 8 of > t/ssl/proxy.t. > The request times out with a 504 status. So it looks like the "backend" in > this request does not respond. > Used MPM is Event,

Re: HTTP/2 in massive file transfers

Just to give some numbers from my laptop, testing against localhost: httpd mpm worker, OS X, client h2load, transfer rates in GByte/s Version #requests2.4.18 2.4.x 1 GB resource h2c clear 1*1 0.017 1.0 8*1 2.2 h2 tls

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On 14 Mar 2016, at 10:32 AM, Yann Ylavic wrote: > Since apr_pollfd_t is not opaque (unlike apr_socket_t), maybe we could > remove the indirection here (and in the code below) with somthing like > (apr_pollfd_t *pfds, size_t npfds, ...). > That would allow a single

Re: [Patch] mod_tcp / mod_proxy_tcp / mod_ssl_tcp

On 14 Mar 2016, at 11:01 AM, Yann Ylavic wrote: >> The following patch provides support for TCP proxying to httpd. >> >> It consists of the following three parts: >> >> - mod_tcp: Allows the frontend to receive pure TCP connections > > It looks like this module is only

Re: r1619483

Hi Christophe, On Sun, Mar 13, 2016 at 10:21 PM, Christophe JAILLET wrote: > Hi, > > while looking at potential backport to synch and trunk, I arrived on > r1619483. > > This is a follow up of r1619444 which is a follow up of r1619383. > These 2 have been

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

> Am 14.03.2016 um 09:32 schrieb Yann Ylavic : > > On Mon, Mar 14, 2016 at 12:41 AM, Graham Leggett wrote: >> On 13 Mar 2016, at 10:55 PM, Eric Covener wrote: >> >>> I also meant the original feature never made it, so we can whatever

Re: [Patch] mod_tcp / mod_proxy_tcp / mod_ssl_tcp

On Sat, Mar 12, 2016 at 4:46 PM, Graham Leggett wrote: > > The following patch provides support for TCP proxying to httpd. > > It consists of the following three parts: > > - mod_tcp: Allows the frontend to receive pure TCP connections It looks like this module is only needed

Re: svn commit: r1734656 - in /httpd/httpd/trunk: ./ include/ modules/http/ server/ server/mpm/event/ server/mpm/motorz/ server/mpm/simple/

On 03/12/2016 01:43 AM, minf...@apache.org wrote: > Author: minfrin > Date: Sat Mar 12 00:43:58 2016 > New Revision: 1734656 > > URL: http://svn.apache.org/viewvc?rev=1734656=rev > Log: > core: Extend support for setting aside data from the network input filter > to any connection or request

Re: Proposed change to mpm_register_socket_callback(): apr_socket_t -> apr_pollfd_t

On Mon, Mar 14, 2016 at 12:41 AM, Graham Leggett wrote: > On 13 Mar 2016, at 10:55 PM, Eric Covener wrote: > >> I also meant the original feature never made it, so we can whatever we >> want to it. > > What do you think of this? Looks good and indeed very