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
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
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
> 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
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
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
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
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
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
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
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
>>
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
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
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
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
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
>>
> 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,
> 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
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
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
20 matches
Mail list logo