Re: HTTP Method Patch

2019-02-20 Thread Christophe JAILLET

Le 20/02/2019 à 14:58, Hajo Locke a écrit :

Hello list,

this is Apache 2.4.34

I was asked if Apache is supporting HTTP Request Methode PATCH.
To be honest i did not really found something useful in the web.
Is Apache supporting this method and is an additionally modul required?
Iam not aware of allowing or forbidding PATCH in httpd.conf

Thanks,
Hajo


Hi,

httpd "understand" the PATCH method (i.e. directive such as 
"AllowMethods PATCH" is accepted), but will do nothing with it.

No modules is provided with httpd to handle the PATCH method.

It is likely that a 405 error ("Method Not Allowed") will be returned, 
unless a third party module able to handle such a method is installed.


CJ



Anyone interested in a freelance opportunity?

2019-02-20 Thread Daniel Ruggeri
Hi, all;
   I was approached to see if I would be interested/willing to work on code to 
support encrypted client keys for the proxy. Unfortunately, I had to pass since 
I just don't have the time, but figured I'd reach out here to see if anyone 
here has the time/expertise/interest.

   I know it's an odd thing to ask, but thought it's worth bringing up because 
I'd personally love to see this functionality :-)

Feel free to reply directly to me if you don't want to share with the list.
-- 
Daniel Ruggeri

Re: svn commit: r1853939 - /httpd/httpd/branches/2.4.x/STATUS

2019-02-20 Thread Yann Ylavic
Included, thanks Stefan!

On Wed, Feb 20, 2019 at 4:57 PM ste...@eissing.org  wrote:
>
> Ok, got a fix in r1853967 and propose to include in mod_reqtimeout backport.
>
> Cheers, Stefan
>
> > Am 20.02.2019 um 16:09 schrieb ste...@eissing.org:
> >
> > Ok, I think I understood:
> >
> > - On a h2 slave connection, slave->keepalives is always > 0, to keep 
> > certain parts of our server from thinking "Oh, this is the first request!"
> > - mod_reqtimeout interprets this as "we are inbetween requests", 
> > ccfg->in_keep_alive != 0
> > - mod_reqtimeout.c:184+ input filter does a speculative read and expects to 
> > see either an error or some data
> > - if not, it return the spec read status
> > - Here, in the failure case, the base slave_in filter return APR_EAGAIN
> >  * this was a fix to prevent ap_check_pipeline() from closing the 
> > connection when seeing APR_SUCCESS with 0 bytes
> > - The read itself is, in the test case, done by mod_cgid which on != 
> > APR_SUCCESS fails with a 400 response
> >
> > The patch did not really change this behaviour, but it changed the 
> > initialization order.
> >
> > Why does this only trigger in this new test case?
> > - Sending requests via mod_proxy_http2 changes the timings of EOF 
> > detection. When the EOF is not signalled on the header frame, the request 
> > body is indeterminate until a DATA frame with EOF arrives. That may happen 
> > after mod_reqtimeout checks.
> > - the slave input filter gets called with a SPEC read of 1 byte, has no 
> > data and also has not seen an EOF. It returns ARP_EAGAIN.
> >
> > What to do?
> > - I think the mod_reqtimeout patch is mostly correct and it should be be 
> > active on h2 slave connections as well
> > - But maybe mod_reqtimeout needs slightly different behaviour on a slave 
> > connection. maybe the keepalives spec reads need to be abandoned here.
> > - Changing the return code of the h2 slave input filter to return 
> > APR_SUCCESS on the speculative read will not really help. mod_reqtimeout 
> > will return this to the caller as there was no data. This means that 
> > mod_cgid will just call it again in a infinite loop until either data or an 
> > EOF arrives. That does not seem good either.
> >
> > Any other ideas?
> >
> > -Stefan
> >
> >> Am 20.02.2019 um 15:14 schrieb ste...@eissing.org:
> >>
> >>
> >>
> >>> Am 20.02.2019 um 10:53 schrieb yla...@apache.org:
> >>>
> >>> Author: ylavic
> >>> Date: Wed Feb 20 09:53:30 2019
> >>> New Revision: 1853939
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1853939=rev
> >>> Log:
> >>> Propose.
> >>>
> >>> Modified:
> >>>  httpd/httpd/branches/2.4.x/STATUS
> >>>
> >>> Modified: httpd/httpd/branches/2.4.x/STATUS
> >>> URL: 
> >>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1853939=1853938=1853939=diff
> >>> ==
> >>> --- httpd/httpd/branches/2.4.x/STATUS (original)
> >>> +++ httpd/httpd/branches/2.4.x/STATUS Wed Feb 20 09:53:30 2019
> >>> @@ -246,6 +246,23 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
> >>>2.4.x patch: 
> >>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-forward_100_continue-v3.patch
> >>>+1: ylavic
> >>>
> >>> +  *) mod_reqtimeout: Allow to configure (TLS-)handshake timeouts.  PR 
> >>> 61310.
> >>> + trunk patch: http://svn.apache.org/r1853901
> >>> +  http://svn.apache.org/r1853906
> >>> +  http://svn.apache.org/r1853908
> >>> +  http://svn.apache.org/r1853929
> >>> +  http://svn.apache.org/r1853935
> >>> + 2.4.x patch: 
> >>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-reqtimeout_handshake.patch
> >>> + +1: ylavic
> >>
> >> This one is giving me headaches. I added test_600_01 to master at 
> >> https://github.com/icing/mod_h2 that triggers it.
> >>
> >> My suspicion is that mod_reqtimeout and mod_http2 need some more 
> >> coordination. While the handshake timeout is very useful also for h2 
> >> connections, waiting for GETLINE or such is less useful.
> >>
> >> There is more than one path how a connection can go from h1 to h2 (alpn, 
> >> direct 24 bytes detection, h1 upgrade:). Direct h2 use by curl/nghttp 
> >> works, but mod_proxy_http2 does not.
> >>
> >> We have a hook for protocol switching: ap_hook_protocol_switch(...) and 
> >> probably mod_reqtimeout needs to listen to that and changes its (at least 
> >> part of the) input/output filtering accordingly.
> >>
> >> I will try to understand how things go sideways with the change and report 
> >> back here.
> >>
> >> -Stefan
> >
>


Re: svn commit: r1853939 - /httpd/httpd/branches/2.4.x/STATUS

2019-02-20 Thread ste...@eissing.org
Ok, got a fix in r1853967 and propose to include in mod_reqtimeout backport.

Cheers, Stefan

> Am 20.02.2019 um 16:09 schrieb ste...@eissing.org:
> 
> Ok, I think I understood:
> 
> - On a h2 slave connection, slave->keepalives is always > 0, to keep certain 
> parts of our server from thinking "Oh, this is the first request!"
> - mod_reqtimeout interprets this as "we are inbetween requests", 
> ccfg->in_keep_alive != 0
> - mod_reqtimeout.c:184+ input filter does a speculative read and expects to 
> see either an error or some data
> - if not, it return the spec read status
> - Here, in the failure case, the base slave_in filter return APR_EAGAIN
>  * this was a fix to prevent ap_check_pipeline() from closing the connection 
> when seeing APR_SUCCESS with 0 bytes
> - The read itself is, in the test case, done by mod_cgid which on != 
> APR_SUCCESS fails with a 400 response
> 
> The patch did not really change this behaviour, but it changed the 
> initialization order. 
> 
> Why does this only trigger in this new test case?
> - Sending requests via mod_proxy_http2 changes the timings of EOF detection. 
> When the EOF is not signalled on the header frame, the request body is 
> indeterminate until a DATA frame with EOF arrives. That may happen after 
> mod_reqtimeout checks.
> - the slave input filter gets called with a SPEC read of 1 byte, has no data 
> and also has not seen an EOF. It returns ARP_EAGAIN.
> 
> What to do?
> - I think the mod_reqtimeout patch is mostly correct and it should be be 
> active on h2 slave connections as well
> - But maybe mod_reqtimeout needs slightly different behaviour on a slave 
> connection. maybe the keepalives spec reads need to be abandoned here.
> - Changing the return code of the h2 slave input filter to return APR_SUCCESS 
> on the speculative read will not really help. mod_reqtimeout will return this 
> to the caller as there was no data. This means that mod_cgid will just call 
> it again in a infinite loop until either data or an EOF arrives. That does 
> not seem good either.
> 
> Any other ideas?
> 
> -Stefan
> 
>> Am 20.02.2019 um 15:14 schrieb ste...@eissing.org:
>> 
>> 
>> 
>>> Am 20.02.2019 um 10:53 schrieb yla...@apache.org:
>>> 
>>> Author: ylavic
>>> Date: Wed Feb 20 09:53:30 2019
>>> New Revision: 1853939
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1853939=rev
>>> Log:
>>> Propose.
>>> 
>>> Modified:
>>>  httpd/httpd/branches/2.4.x/STATUS
>>> 
>>> Modified: httpd/httpd/branches/2.4.x/STATUS
>>> URL: 
>>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1853939=1853938=1853939=diff
>>> ==
>>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>>> +++ httpd/httpd/branches/2.4.x/STATUS Wed Feb 20 09:53:30 2019
>>> @@ -246,6 +246,23 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>>2.4.x patch: 
>>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-forward_100_continue-v3.patch
>>>+1: ylavic
>>> 
>>> +  *) mod_reqtimeout: Allow to configure (TLS-)handshake timeouts.  PR 
>>> 61310.
>>> + trunk patch: http://svn.apache.org/r1853901
>>> +  http://svn.apache.org/r1853906
>>> +  http://svn.apache.org/r1853908
>>> +  http://svn.apache.org/r1853929
>>> +  http://svn.apache.org/r1853935
>>> + 2.4.x patch: 
>>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-reqtimeout_handshake.patch
>>> + +1: ylavic
>> 
>> This one is giving me headaches. I added test_600_01 to master at 
>> https://github.com/icing/mod_h2 that triggers it.
>> 
>> My suspicion is that mod_reqtimeout and mod_http2 need some more 
>> coordination. While the handshake timeout is very useful also for h2 
>> connections, waiting for GETLINE or such is less useful. 
>> 
>> There is more than one path how a connection can go from h1 to h2 (alpn, 
>> direct 24 bytes detection, h1 upgrade:). Direct h2 use by curl/nghttp works, 
>> but mod_proxy_http2 does not.
>> 
>> We have a hook for protocol switching: ap_hook_protocol_switch(...) and 
>> probably mod_reqtimeout needs to listen to that and changes its (at least 
>> part of the) input/output filtering accordingly.
>> 
>> I will try to understand how things go sideways with the change and report 
>> back here.
>> 
>> -Stefan
> 



Re: svn commit: r1853939 - /httpd/httpd/branches/2.4.x/STATUS

2019-02-20 Thread ste...@eissing.org
Ok, I think I understood:

- On a h2 slave connection, slave->keepalives is always > 0, to keep certain 
parts of our server from thinking "Oh, this is the first request!"
- mod_reqtimeout interprets this as "we are inbetween requests", 
ccfg->in_keep_alive != 0
- mod_reqtimeout.c:184+ input filter does a speculative read and expects to see 
either an error or some data
- if not, it return the spec read status
- Here, in the failure case, the base slave_in filter return APR_EAGAIN
  * this was a fix to prevent ap_check_pipeline() from closing the connection 
when seeing APR_SUCCESS with 0 bytes
- The read itself is, in the test case, done by mod_cgid which on != 
APR_SUCCESS fails with a 400 response

The patch did not really change this behaviour, but it changed the 
initialization order. 

Why does this only trigger in this new test case?
- Sending requests via mod_proxy_http2 changes the timings of EOF detection. 
When the EOF is not signalled on the header frame, the request body is 
indeterminate until a DATA frame with EOF arrives. That may happen after 
mod_reqtimeout checks.
- the slave input filter gets called with a SPEC read of 1 byte, has no data 
and also has not seen an EOF. It returns ARP_EAGAIN.

What to do?
- I think the mod_reqtimeout patch is mostly correct and it should be be active 
on h2 slave connections as well
- But maybe mod_reqtimeout needs slightly different behaviour on a slave 
connection. maybe the keepalives spec reads need to be abandoned here.
- Changing the return code of the h2 slave input filter to return APR_SUCCESS 
on the speculative read will not really help. mod_reqtimeout will return this 
to the caller as there was no data. This means that mod_cgid will just call it 
again in a infinite loop until either data or an EOF arrives. That does not 
seem good either.

Any other ideas?

-Stefan

> Am 20.02.2019 um 15:14 schrieb ste...@eissing.org:
> 
> 
> 
>> Am 20.02.2019 um 10:53 schrieb yla...@apache.org:
>> 
>> Author: ylavic
>> Date: Wed Feb 20 09:53:30 2019
>> New Revision: 1853939
>> 
>> URL: http://svn.apache.org/viewvc?rev=1853939=rev
>> Log:
>> Propose.
>> 
>> Modified:
>>   httpd/httpd/branches/2.4.x/STATUS
>> 
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1853939=1853938=1853939=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Wed Feb 20 09:53:30 2019
>> @@ -246,6 +246,23 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>> 2.4.x patch: 
>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-forward_100_continue-v3.patch
>> +1: ylavic
>> 
>> +  *) mod_reqtimeout: Allow to configure (TLS-)handshake timeouts.  PR 61310.
>> + trunk patch: http://svn.apache.org/r1853901
>> +  http://svn.apache.org/r1853906
>> +  http://svn.apache.org/r1853908
>> +  http://svn.apache.org/r1853929
>> +  http://svn.apache.org/r1853935
>> + 2.4.x patch: 
>> http://people.apache.org/~ylavic/patches/httpd-2.4.x-reqtimeout_handshake.patch
>> + +1: ylavic
> 
> This one is giving me headaches. I added test_600_01 to master at 
> https://github.com/icing/mod_h2 that triggers it.
> 
> My suspicion is that mod_reqtimeout and mod_http2 need some more 
> coordination. While the handshake timeout is very useful also for h2 
> connections, waiting for GETLINE or such is less useful. 
> 
> There is more than one path how a connection can go from h1 to h2 (alpn, 
> direct 24 bytes detection, h1 upgrade:). Direct h2 use by curl/nghttp works, 
> but mod_proxy_http2 does not.
> 
> We have a hook for protocol switching: ap_hook_protocol_switch(...) and 
> probably mod_reqtimeout needs to listen to that and changes its (at least 
> part of the) input/output filtering accordingly.
> 
> I will try to understand how things go sideways with the change and report 
> back here.
> 
> -Stefan



Re: svn commit: r1853939 - /httpd/httpd/branches/2.4.x/STATUS

2019-02-20 Thread ste...@eissing.org



> Am 20.02.2019 um 10:53 schrieb yla...@apache.org:
> 
> Author: ylavic
> Date: Wed Feb 20 09:53:30 2019
> New Revision: 1853939
> 
> URL: http://svn.apache.org/viewvc?rev=1853939=rev
> Log:
> Propose.
> 
> Modified:
>httpd/httpd/branches/2.4.x/STATUS
> 
> Modified: httpd/httpd/branches/2.4.x/STATUS
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1853939=1853938=1853939=diff
> ==
> --- httpd/httpd/branches/2.4.x/STATUS (original)
> +++ httpd/httpd/branches/2.4.x/STATUS Wed Feb 20 09:53:30 2019
> @@ -246,6 +246,23 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>  2.4.x patch: 
> http://people.apache.org/~ylavic/patches/httpd-2.4.x-forward_100_continue-v3.patch
>  +1: ylavic
> 
> +  *) mod_reqtimeout: Allow to configure (TLS-)handshake timeouts.  PR 61310.
> + trunk patch: http://svn.apache.org/r1853901
> +  http://svn.apache.org/r1853906
> +  http://svn.apache.org/r1853908
> +  http://svn.apache.org/r1853929
> +  http://svn.apache.org/r1853935
> + 2.4.x patch: 
> http://people.apache.org/~ylavic/patches/httpd-2.4.x-reqtimeout_handshake.patch
> + +1: ylavic

This one is giving me headaches. I added test_600_01 to master at 
https://github.com/icing/mod_h2 that triggers it.

My suspicion is that mod_reqtimeout and mod_http2 need some more coordination. 
While the handshake timeout is very useful also for h2 connections, waiting for 
GETLINE or such is less useful. 

There is more than one path how a connection can go from h1 to h2 (alpn, direct 
24 bytes detection, h1 upgrade:). Direct h2 use by curl/nghttp works, but 
mod_proxy_http2 does not.

We have a hook for protocol switching: ap_hook_protocol_switch(...) and 
probably mod_reqtimeout needs to listen to that and changes its (at least part 
of the) input/output filtering accordingly.

I will try to understand how things go sideways with the change and report back 
here.

-Stefan

AW: svn commit: r1853953 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c

2019-02-20 Thread Plüm , Rüdiger , Vodafone Group
My bad. I misread the diff. It was there in stream_reqbody_chunked and 
stream_reqbody_cl. So the condition is correct.

Regards

Rüdiger


C2 General

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Mittwoch, 20. Februar 2019 14:25
> An: httpd-dev 
> Betreff: Re: svn commit: r1853953 -
> /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
> 
> On Wed, Feb 20, 2019 at 2:04 PM Ruediger Pluem 
> wrote:
> >
> > Shouldn't we add (rb_method == RB_STREAM_CHUNKED) as condition to the
> above if as this only seems to make sense in the chunked encoding case?
> 
> Well, I think it makes no sense in both cases, but it was there in
> stream_reqbody_cl() so I thought I'd keep it..
> 
> Regards,
> Yann.


Re: svn commit: r1853953 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c

2019-02-20 Thread Yann Ylavic
On Wed, Feb 20, 2019 at 2:04 PM Ruediger Pluem  wrote:
>
> Shouldn't we add (rb_method == RB_STREAM_CHUNKED) as condition to the above 
> if as this only seems to make sense in the chunked encoding case?

Well, I think it makes no sense in both cases, but it was there in
stream_reqbody_cl() so I thought I'd keep it..

Regards,
Yann.


Re: svn commit: r1853901 - /httpd/httpd/trunk/modules/filters/mod_reqtimeout.c

2019-02-20 Thread Yann Ylavic
On Wed, Feb 20, 2019 at 8:05 AM Ruediger Pluem  wrote:
>
> On 2019/02/19 17:21:09, yla...@apache.org wrote:
> >
> > -#define MERGE_INT(cfg, b, a, val) cfg->val = (a->val == UNSET) ? b->val : 
> > a->val;
> > +#define MERGE_INT(cfg, b, a, val) \
> > +cfg->val = (a->val == UNSET) ? b->val : a->val
> > +#define MERGE_STAGE(cfg, b, a, stage) do { \
>
> Shouldn't this be
>
> #define MERGE_STAGE(cfg, base, add, stage) do { \
>
> > +MERGE_INT(cfg, base, add, stage.timeout); \
> > +MERGE_INT(cfg, base, add, stage.max_timeout); \
> > +MERGE_INT(cfg, base, add, stage.min_rate); \
> > +cfg->stage.rate_factor = (cfg->stage.min_rate == UNSET) \
> > + ? base->stage.rate_factor \
> > + : add->stage.rate_factor; \
> > +} while (0)
> > +

Ah yes, thanks! Fixed in r1853929.

Regards,
Yann.