Re: h2_proxy_util.c, is this going make 2.4.21?

[William A Rowe Jr]

On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith  wrote:

> I have the to connect this module in the traditional windows build but as
> of right now it's using h2_util.c which Bill had an objection to. See his
> comments http://marc.info/?l=apache-httpd-dev=146543811201820=2
>
> So to me that seems to be a -1 to mod_proxy_http2, at minimum on Windows.
> In trunk Stefan seems to have chosen option 3 in Bill's list and that is
> h2_proxy_util.c.
>
> If I knew that was going to be backported I would add the rest of the bits
> needed to use h2_proxy_util.c. If it is not going to make it, then I will
> not commit anything and there will be no mod_proxy_http2 in 2.4.21 on
> Windows. If this gets in overnight and you tag in the morning, I may not be
> out of bed yet due to the time difference.
>
> That's where my concern is. Make sense?


Shouldn't be a concern. I'm mildly concerned about the single-level
namespace
collisions on Unix, but because the .so object is pre-linked to its own
functions
before anything is imported/exported, mod_http2.so should be using
h2_utils.o
and mod_proxy_http2.so should be using h2_proxy_utils.o, even without any
additional namespace protection. A third module trying to use the functions
of
those two modules could cause headaches, but that can be addressed later.

Windows has two-level namespaces, so there is no ambiguity between symbols
in one .so (.dll) and a second, unless you are simultaneously linking a
module
to both of these modules.

I accept Stefan's proposed fix for the time being, and we can certainly make
this simpler on trunk in the future.

Cheers,

Bill

Re: h2_proxy_util.c, is this going make 2.4.21?

[Stefan Eissing]

I won't be able to do this today, but can tomorrow. Otherwise anyone with time 
to merge back the change, please do. 

> Am 13.06.2016 um 20:59 schrieb Gregg Smith :
> 
> I have the to connect this module in the traditional windows build but as of 
> right now it's using h2_util.c which Bill had an objection to. See his 
> comments http://marc.info/?l=apache-httpd-dev=146543811201820=2
> 
> So to me that seems to be a -1 to mod_proxy_http2, at minimum on Windows. In 
> trunk Stefan seems to have chosen option 3 in Bill's list and that is 
> h2_proxy_util.c.
> 
> If I knew that was going to be backported I would add the rest of the bits 
> needed to use h2_proxy_util.c. If it is not going to make it, then I will not 
> commit anything and there will be no mod_proxy_http2 in 2.4.21 on Windows. If 
> this gets in overnight and you tag in the morning, I may not be out of bed 
> yet due to the time difference.
> 
> That's where my concern is. Make sense?
> 
> 
>> On 6/13/2016 11:43 AM, Jim Jagielski wrote:
>> What needs to be done?
>> 
>>> On Jun 13, 2016, at 2:20 PM, Gregg Smith  wrote:
>>> 
>>> Hi Stefan,
>>> 
>>> Any plans to backport this before Jim tags 2.4.21 tomorrow?
>>> 
>>> Thanks,
>>> 
>>> Gregg
> 

Re: h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

I have the to connect this module in the traditional windows build but 
as of right now it's using h2_util.c which Bill had an objection to. See 
his comments http://marc.info/?l=apache-httpd-dev=146543811201820=2


So to me that seems to be a -1 to mod_proxy_http2, at minimum on 
Windows. In trunk Stefan seems to have chosen option 3 in Bill's list 
and that is h2_proxy_util.c.


If I knew that was going to be backported I would add the rest of the 
bits needed to use h2_proxy_util.c. If it is not going to make it, then 
I will not commit anything and there will be no mod_proxy_http2 in 
2.4.21 on Windows. If this gets in overnight and you tag in the morning, 
I may not be out of bed yet due to the time difference.


That's where my concern is. Make sense?


On 6/13/2016 11:43 AM, Jim Jagielski wrote:

What needs to be done?


On Jun 13, 2016, at 2:20 PM, Gregg Smith  wrote:

Hi Stefan,

Any plans to backport this before Jim tags 2.4.21 tomorrow?

Thanks,

Gregg

Re: Multiple patches; any takers before T?

[Jacob Champion]

On 06/12/2016 06:35 AM, Jim Jagielski wrote:

After the T, I will apply to trunk and then they will be available
for backport next time (assuming no issues w/ the patches, 'natch)


Thanks Jim! It looks like two of the four (DUMP_INCLUDES and proxy:fcgi) 
were applied to trunk over the weekend. That leaves the APXS and Windows 
CMake fixes for review.


--Jacob

Re: h2_proxy_util.c, is this going make 2.4.21?

[Jim Jagielski]

What needs to be done?

> On Jun 13, 2016, at 2:20 PM, Gregg Smith  wrote:
> 
> Hi Stefan,
> 
> Any plans to backport this before Jim tags 2.4.21 tomorrow?
> 
> Thanks,
> 
> Gregg
> 

h2_proxy_util.c, is this going make 2.4.21?

[Gregg Smith]

Hi Stefan,

Any plans to backport this before Jim tags 2.4.21 tomorrow?

Thanks,

Gregg

T Of 2.4.21 on Tues (June 14)

[Jim Jagielski]

I am looking to T 2.4.21 tomorrow (Tues) with a hoped-for
release on Friday.

> On Jun 8, 2016, at 9:34 AM, Jim Jagielski  wrote:
> 
> I am thinking about a T next week...
> 
> Get those backports and votes IN!
> 
>> On May 23, 2016, at 9:32 AM, Jim Jagielski  wrote:
>> 
>> Just a FYI: With http/2 and dynamic health checks now in
>> 2.4.x's reverse proxy, I will push for a release of 2.4.21
>> for early June.
>> 
>> We need to continue to show that Apache httpd is leading tech
>> in web server IT, and these enhancements are proof positive
>> of that.
>> 
>> I will RM.
> 

Re: svn commit: r1748155 - /httpd/httpd/trunk/modules/dav/main/mod_dav.h

[Ruediger Pluem]

On 06/13/2016 11:53 AM, Stefan Eissing wrote:
> Hmm, there is a "typedef struct dav_response dav_response" further and the 
> new typedef of the same struct gave an error in clang. I thought this was the 
> best way to fix this...

I missed that "typedef struct dav_response dav_response". All good. Sorry for 
the noise.

Regards

Rüdiger

Random AH01842 errors in mod_session_crypto

[Ewald Dieterich]

I configured form authentication with mod_auth_form, mod_session_cookie 
and mod_session_crypto in Apache 2.4.20 on Debian unstable and get 
random AH01842 errors ("decrypt session failed, wrong passphrase"). The 
passphrase was not changed when this happens.


It looks like the error occurs when the following conditions are met:

* mpm_worker enabled (never experienced the error with mpm_prefork)
* Same user doing multiple requests in parallel using the same session 
(don't see the error when the user is doing only sequential requests)


I already added some debug logging to check the passphrase and it's 
always the same for both encryption and decryption when the error occurs.


To reproduce the error I wrote a Perl script that logs in and then 
requests a protected page in an endless loop and start the script 
multiple times. It still can take quite some time for the error to 
occur, but it's the best I came up with for easy reproduction. In cases 
reported "from the field" with real users, real browsers and real Web 
applications the error occurs much more frequently.


Does anyone want to look into this? I can give more information about a 
test setup and the Perl script if that's the case. Any help would be 
really appreciated.