Re: httpd 2.4.25, mpm_event, ssl: segfaults

[Niklas Edmundsson]

On Mon, 6 Feb 2017, Jacob Champion wrote:



Considering the massive amount of caching that's built into the entire HTTP 
ecosystem already, O_DIRECT *might* be an effective way to do that (in which 
we give up filesystem optimizations and caching in return for a DMA into 
userspace). I have a PoC about halfway done, but I need to split my time this 
week between this and the FCGI stuff I've been neglecting.


As O_DIRECT bypasses the cache, all your IO will hit your storage 
device. I think this makes it useful only in exotic usecases.


For our workload that's using mod_cache with a local disk cache we 
still want to use the remaining RAM as a disk read cache, it doesn't 
make sense to force disk I/O for files that simply could have been 
served from RAM. We typically see 90-95% of the requests served by 
mod_cache actually being served from the disk cache in RAM rather than 
hitting the local disk cache devices. I'm suspecting the picture is 
similar for most occurrances of static file serving, regardless of 
using mod_cache etc or not.


O_DIRECT also bypasses any read-ahead logic, so you'll have to do nice 
and big IO etc to get good performance.


We've played around with O_DIRECT to optimize the caching process in 
our large-file caching module (our backing store is nfs). However, 
since all our hosts are running Linux we had much better results with 
doing plain reads and utilizing posix_fadvise with POSIX_FADV_WILLNEED 
to trigger read-ahead and POSIX_FADV_DONTNEED to drop the original 
file from cache when read (as future requests will be served from 
local disk cache). We're doing 8MB fadvise chunks to get full 
streaming performance when caching large files.


But that's way out of scope for this discussion, I think ;-)

In conclusion, I wouldn't expect any benefits of using O_DIRECT in the 
common httpd usecases. That said, I would gladly be proven wrong :)


/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
---
 "The point is I am now a perfectly safe penguin!" -- Ford Prefect
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: httpd 2.4.25, mpm_event, ssl: segfaults

[Daniel Lescohier]

Here is how cache page replacement is done in Linux:
https://linux-mm.org/PageReplacementDesign


On Tue, Feb 7, 2017 at 5:32 AM, Niklas Edmundsson  wrote:

> On Mon, 6 Feb 2017, Jacob Champion wrote:
>
> 
>
> Considering the massive amount of caching that's built into the entire
>> HTTP ecosystem already, O_DIRECT *might* be an effective way to do that (in
>> which we give up filesystem optimizations and caching in return for a DMA
>> into userspace). I have a PoC about halfway done, but I need to split my
>> time this week between this and the FCGI stuff I've been neglecting.
>>
>
> As O_DIRECT bypasses the cache, all your IO will hit your storage device.
> I think this makes it useful only in exotic usecases.
>
> For our workload that's using mod_cache with a local disk cache we still
> want to use the remaining RAM as a disk read cache, it doesn't make sense
> to force disk I/O for files that simply could have been served from RAM. We
> typically see 90-95% of the requests served by mod_cache actually being
> served from the disk cache in RAM rather than hitting the local disk cache
> devices. I'm suspecting the picture is similar for most occurrances of
> static file serving, regardless of using mod_cache etc or not.
>
> O_DIRECT also bypasses any read-ahead logic, so you'll have to do nice and
> big IO etc to get good performance.
>
> We've played around with O_DIRECT to optimize the caching process in our
> large-file caching module (our backing store is nfs). However, since all
> our hosts are running Linux we had much better results with doing plain
> reads and utilizing posix_fadvise with POSIX_FADV_WILLNEED to trigger
> read-ahead and POSIX_FADV_DONTNEED to drop the original file from cache
> when read (as future requests will be served from local disk cache). We're
> doing 8MB fadvise chunks to get full streaming performance when caching
> large files.
>
> But that's way out of scope for this discussion, I think ;-)
>
> In conclusion, I wouldn't expect any benefits of using O_DIRECT in the
> common httpd usecases. That said, I would gladly be proven wrong :)
>
> /Nikke
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> -=-=-=-=-=-=-=-
>  Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se  | ni...@acc.umu.se
> 
> ---
>  "The point is I am now a perfectly safe penguin!" -- Ford Prefect
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> =-=-=-=-=-=-=-=
>

mood_remoteip ProxyProtocol addition

[Sander Hoentjen]

Hi guys,

I am trying to have haproxy added in front of our Apache servers, for
SSL termination. This is not hard to do, and especially with the recent
addition of ProxyProtocol support to mod_remoteip it works almost as we
need it.
Unfortunately we have a lot of users that use things like:
RewriteCond %{HTTPS} !on
in their .htaccess, and stuff like:
if $_SERVER['HTTPS']
in their PHP code.

Long story short, I need httpd to act like SSL is on, if the haproxy
instance says it is.
Fortunately the proxy protocol supports this, and haproxy can send it.
I have created a patch [1] that adds support for reading this in httpd,
but I have never before done something with the httpd source code. And,
as a matter of fact, have never really programmed in C before.

I am hoping you would be willing to have a look at it and tell me all
the things I am doing wrong. Eventually it would be awesome if the code
could be added to apache itself.

[1] https://github.com/AntagonistHQ/httpd/tree/remote-ssl

Kind regards,
Sander Hoentjen

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Hi,

got this one today with both patches applied:

Core was generated by `/usr/local/apache/bin/httpd -DFOREGROUND'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f350405e030)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f350405e030)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f3504060468) at memory/unix/apr_pools.c:793
#2  0x55d11256d688 in ap_push_pool (queue_info=0x7f35040604f8,
pool_to_recycle=0x) at fdqueue.c:234
#3  0x55d11256899a in process_lingering_close (cs=0x7f3504060748,
pfd=0x55d1143fd7f8) at event.c:1513
#4  0x55d11256c4d0 in listener_thread (thd=0x7f35040604f8,
dummy=0x547f569acd4a6) at event.c:1837
#5  0x7f351757c0a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f35172b162d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Am 06.02.2017 um 22:24 schrieb Stefan Priebe - Profihost AG:
> Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>>
>> this one does not apply on top of yann's
>> mpm_event_listener_wakeup_bug57399_V7.patch patch.
> 
> i've now used his patch to mpm and yours for mod_http2.
> 
> Stefan
> 
>>
>> Stefan
>> Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
>>> Yes, that was mixing the order. The attached v4 compiles and runs the h2 
>>> tests for me without errors.
>>>
>>>
>>>
>>>
>>>
 Am 06.02.2017 um 14:43 schrieb Yann Ylavic :

 On Mon, Feb 6, 2017 at 2:31 PM, Stefan Eissing
  wrote:
> Currently running some tests. Have crashes on the original patch in my 
> test suite. Fixed one, hunting for the next...

 I think it comes from my change that creates slave connections from
 master->pool (instead of mplx's), because now slave's pool is already
 destroyed when 
 h2_mplx_release_and_join()->task_destroy()->h2_slave_destroy()
 is called (hence the crash).

 I restored your original code in this new (attached) patch.

 @s.priebe, would you test this one please?
 
>>>
>>> Stefan Eissing
>>>
>>> bytes GmbH
>>> Hafenstrasse 16
>>> 48155 Münster
>>> www.greenbytes.de
>>>

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov  wrote:
> On 7 February 2017 at 22:33, Yann Ylavic  wrote:
>> I'm a bit reluctant with these patches, and probably need to be
>> convinced this isn't an application issue in the first place (why not
>> use X-Forwarded-Proto or alike to achieve the same? i.e. generate
>> https links...), or an SSL endpoint issue (why not rewrite URLs or
>> alike there?).
> It can be X-Forwarded-Proto or whatever you set it to with my patch
> (for the standard method of proxying).
> I can't speak to the ProxyProtocol one.
>
> I also don't see what you mean by an "application issue".

I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes).

>
>>
>> My point is that we are not changing/masquarading something which is
>> remote here (like the client IP address), we are making so that the
>> applications and httpd itself think they are locally talking SSL/TLS.
>> Thus they will send things like "; Secure" cookies in "clear" on the
>> wire, or anything which is expected to not be eavesdrop-able.
> The whole point of the mod_remoteip is that it tells you the request
> is forwarded by a trusted source, usually over an internal network, so
> I don't see what eavesdropping

It tells you what remote information of the request is trustable,
which is not the same (IMHO) as a local information like _this_ server
(running the application) is using https.

>
>> I'd like others from the community to give their opinions here, for
>> now I find this quite opposite to TLS principles/expectations...
> It's made to work much like Apache Tomcat's RemoteIPValve. Different
> language, same principal.
>
> I've only used a few PHP frameworks, but whenever they require
> checking if the server is secure and redirecting if not, they always
> fall back on these three variables that are changed.
> HTTPS = on
> REQUEST_SCHEME = https
> SERVER_PORT = 443 (some times configurable).

That's what I called an application issue, I don't see why PHP
wouldn't trust other variables if PHP users want to, or the
application/script force those (or whatever) for _PHP_ to act as if,
or the act as if directly...

Why would the server lie? I'd be fine with the server setting
REMOTE_HTTPS=on and/or REMOTE_SCHEME=https, though.

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 7:03 PM, Jordan Gigov  wrote:
> On 7 February 2017 at 18:08, Sander Hoentjen  wrote:
>>
>> I am trying to have haproxy added in front of our Apache servers, for
>> SSL termination. This is not hard to do, and especially with the recent
>> addition of ProxyProtocol support to mod_remoteip it works almost as we
>> need it.
>> Unfortunately we have a lot of users that use things like:
>> RewriteCond %{HTTPS} !on
>> in their .htaccess, and stuff like:
>> if $_SERVER['HTTPS']
>> in their PHP code.
>>
>> [1] https://github.com/AntagonistHQ/httpd/tree/remote-ssl
>
> I submitted an issue and a patch for that some time ago.
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59829

I'm a bit reluctant with these patches, and probably need to be
convinced this isn't an application issue in the first place (why not
use X-Forwarded-Proto or alike to achieve the same? i.e. generate
https links...), or an SSL endpoint issue (why not rewrite URLs or
alike there?).

My point is that we are not changing/masquarading something which is
remote here (like the client IP address), we are making so that the
applications and httpd itself think they are locally talking SSL/TLS.
Thus they will send things like "; Secure" cookies in "clear" on the
wire, or anything which is expected to not be eavesdrop-able.

I'd like others from the community to give their opinions here, for
now I find this quite opposite to TLS principles/expectations...


Regards,
Yann.

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 7 February 2017 at 22:33, Yann Ylavic  wrote:
> I'm a bit reluctant with these patches, and probably need to be
> convinced this isn't an application issue in the first place (why not
> use X-Forwarded-Proto or alike to achieve the same? i.e. generate
> https links...), or an SSL endpoint issue (why not rewrite URLs or
> alike there?).
It can be X-Forwarded-Proto or whatever you set it to with my patch
(for the standard method of proxying).
I can't speak to the ProxyProtocol one.

I also don't see what you mean by an "application issue".

>
> My point is that we are not changing/masquarading something which is
> remote here (like the client IP address), we are making so that the
> applications and httpd itself think they are locally talking SSL/TLS.
> Thus they will send things like "; Secure" cookies in "clear" on the
> wire, or anything which is expected to not be eavesdrop-able.
The whole point of the mod_remoteip is that it tells you the request
is forwarded by a trusted source, usually over an internal network, so
I don't see what eavesdropping

> I'd like others from the community to give their opinions here, for
> now I find this quite opposite to TLS principles/expectations...
It's made to work much like Apache Tomcat's RemoteIPValve. Different
language, same principal.

I've only used a few PHP frameworks, but whenever they require
checking if the server is secure and redirecting if not, they always
fall back on these three variables that are changed.
HTTPS = on
REQUEST_SCHEME = https
SERVER_PORT = 443 (some times configurable).

Re: Build-tree testing is now in trunk

[Jacob Champion]

On 01/24/2017 07:01 AM, Luca Toscano wrote:

Just tested with trunk, works fine for me! I haven't done anything
special though, will try to do more testing during the next days..


Awesome, thanks for the testing!

I have merged a fix for the MPM-DSO ServerName warnings, so Yann, if you 
want to give that a shot and confirm it works for you, I will propose 
for backport after I feel relatively certain I haven't broken anything.


--Jacob

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:
>
> how can you trust as a php application developer that "X-Forwarded-Proto" is
> trustable and not from the enduser client at all - for REMOTE_ADDR you don't
> consider "X-Forwarded-For" exactly for that reason

I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.

But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic  wrote:
> On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:
>>
>> how can you trust as a php application developer that "X-Forwarded-Proto" is
>> trustable and not from the enduser client at all - for REMOTE_ADDR you don't
>> consider "X-Forwarded-For" exactly for that reason
>
> I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
> that mod_remoteip [either directly or provides the (optional)
> functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
> and/or REMOTE_SCHEME=https accordingly.
> Just like REMOTE_ADDR.
>
> But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
> sources/hooks as accessed and read by core/modules), like (IIUC)
> proposed by the patches.
> These are local informations.

Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.

What's proposed so far is much more than that (if I read the patches correctly).

Re: mood_remoteip ProxyProtocol addition

[Yann Ylavic]

On Tue, Feb 7, 2017 at 11:34 PM, Reindl Harald  wrote:
>
> Am 07.02.2017 um 22:53 schrieb Yann Ylavic:
>>
>> I mean the application can know about "X-Forwarded-Proto or whatever"
>> header, it could act with it like it does with HTTPS=on (if it
>> wishes)
>
> for that you would need to touch each and every application and you have not
> secure way to know for sure if that header is trustable, when mod_remoteip
> is part of the game you even don't know (and should not know) the physical
> connecting IP

I agree with that, "X-Forwarded-Proto or whatever" was meant to say "a
trustable information", and I even agree that's mod_remoteip's job to
give that information.

I just don't think we should make as if httpd were running https (i.e.
for all modules/applications to think it is), but rather give the real
information: trustable remote is running https.

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 23:50 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 11:34 PM, Reindl Harald  wrote:


Am 07.02.2017 um 22:53 schrieb Yann Ylavic:


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have not
secure way to know for sure if that header is trustable, when mod_remoteip
is part of the game you even don't know (and should not know) the physical
connecting IP


I agree with that, "X-Forwarded-Proto or whatever" was meant to say "a
trustable information", and I even agree that's mod_remoteip's job to
give that information.

I just don't think we should make as if httpd were running https (i.e.
for all modules/applications to think it is), but rather give the real
information: trustable remote is running https


with a wayback machine this would be pretty cool, but whatever you do at 
this point in time needs to


a) get implemented in the tls offlaoding software
b) get implemented in the backend-server (httpd)
c) get implemented in each and every web application

while a) and b) are realistic in a mid-term timeframe c) is not and 
additionally c) needs to to it secure


to do it secure is even a real problem

how can you trust as a php application developer that 
"X-Forwarded-Proto" is trustable and not from the enduser client at all 
- for REMOTE_ADDR you don't consider "X-Forwarded-For" exactly for that 
reason


when mod_remoteip is in place "X-Forwarded-For" contains only untrusted 
informations and the ip of your own proxy is ripped out of that header


without mod_remoteip you get unfiltered whatever came over the wire and 
you have no idea within the php application if you are behind a proxy at 
all


at least not trusted one and even if httpd promises in a later version 
that you don't get that header from untrusted sources you have no idea 
if the httpd on your hoster has that promise (LTS distributions with no 
real versions) and there are other webservers too


hence application developers are advised making no decisions based on 
that header - i would find it questionable having a "X-Forwarded-Proto" 
where you have to deal with in the application and "X-Forwarded-For" 
where you *must not* process it for security reasons

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 21:33 schrieb Yann Ylavic:

My point is that we are not changing/masquarading something which is
remote here (like the client IP address), we are making so that the
applications and httpd itself think they are locally talking SSL/TLS.
Thus they will send things like "; Secure" cookies in "clear" on the
wire, or anything which is expected to not be eavesdrop-able.

I'd like others from the community to give their opinions here, for
now I find this quite opposite to TLS principles/expectations...


it's exactly how it should work - proxy to backend unencrypted, caching 
on the proxy and transport security between proxy endpoint and web client


that is what is meant by "TLS offloading" - it's not your problem how 
secure that wire is, on our VMware-cluster the hosts even don#t talk 
about a switch - they are directly connected for internal traffic and so 
that wire is as secure as the virtual machine itself

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 08.02.2017 um 00:44 schrieb Yann Ylavic:

On Wed, Feb 8, 2017 at 12:25 AM, Yann Ylavic  wrote:

On Wed, Feb 8, 2017 at 12:01 AM, Reindl Harald  wrote:


how can you trust as a php application developer that "X-Forwarded-Proto" is
trustable and not from the enduser client at all - for REMOTE_ADDR you don't
consider "X-Forwarded-For" exactly for that reason


I'm not proposing to use or trust "X-Forwarded-Proto" directly, but
that mod_remoteip [either directly or provides the (optional)
functions for ap_add_{common,cgi}_vars() to] set REMOTE_HTTPS=on
and/or REMOTE_SCHEME=https accordingly.
Just like REMOTE_ADDR.

But not change HTTPS and/or REQUEST_SCHEME (but more importantly their
sources/hooks as accessed and read by core/modules), like (IIUC)
proposed by the patches.
These are local informations.


Actually, I'm not really opposed to set HTTPS=on (according to
mod_remoteip) in the environment *given to the script/CGI* only, if
that's the trigger for it to do the desired thing, this won't be used
by httpd internally at least.

What's proposed so far is much more than that (if I read the patches correctly)


ok, so finally we agree :-)

i am only interested in a centralized way to get rid of hacks like below 
in each and every application where mod_remoteip solves the similar 
problem with $_SERVER['REMOTAE_ADDR'] for cgi/mod_php


$_SERVER['REQUEST_SCHEME'] because you typically build a full qualifiied 
URL for a link in emails with $_SERVER['REQUEST_SCHEME'] . '//' . 
$_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] . '?param=x'


in my own application the hack below was simple - in case of other 
software like Magento and so on you have to hack "index.php" while at 
the same time you should not touch the application code to keep it 
easily updateable


if(!empty($config['cms_tls_offload']))
{
 $_SERVER['SERVER_PORT']= '443';
 $_SERVER['REQUEST_SCHEME'] = 'https';
 $_SERVER['HTTPS']  = 'on';
}

Re: mood_remoteip ProxyProtocol addition

[Reindl Harald]

Am 07.02.2017 um 22:53 schrieb Yann Ylavic:

On Tue, Feb 7, 2017 at 10:14 PM, Jordan Gigov  wrote:

On 7 February 2017 at 22:33, Yann Ylavic  wrote:

I'm a bit reluctant with these patches, and probably need to be
convinced this isn't an application issue in the first place (why not
use X-Forwarded-Proto or alike to achieve the same? i.e. generate
https links...), or an SSL endpoint issue (why not rewrite URLs or
alike there?).

It can be X-Forwarded-Proto or whatever you set it to with my patch
(for the standard method of proxying).
I can't speak to the ProxyProtocol one.

I also don't see what you mean by an "application issue".


I mean the application can know about "X-Forwarded-Proto or whatever"
header, it could act with it like it does with HTTPS=on (if it
wishes)


for that you would need to touch each and every application and you have 
not secure way to know for sure if that header is trustable, when 
mod_remoteip is part of the game you even don't know (and should not 
know) the physical connecting IP


and so when you write a application to directly proceed that header you 
make your application vulnerable in every environment where the outside 
client fakes that header


dealing with it the same way as for REMOTE_ADDR would make it 100% 
transparent for the application and it would only trigger if the admin 
configured the underlying server as he does with mod_remoteip's 
"RemoteIPInternalProxy"


it's not a application issue - the application must not know anything 
about infrastructure decisions - it's the job of the underlying 
infrastructure

Re: Build-tree testing is now in trunk

[Yann Ylavic]

On Tue, Feb 7, 2017 at 8:51 PM, Jacob Champion  wrote:
>
> I have merged a fix for the MPM-DSO ServerName warnings, so Yann, if you
> want to give that a shot and confirm it works for you, I will propose for
> backport after I feel relatively certain I haven't broken anything.

Nice, works perfectly for me.

Thanks!

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 8 February 2017 at 01:44, Yann Ylavic  wrote:
> Actually, I'm not really opposed to set HTTPS=on (according to
> mod_remoteip) in the environment *given to the script/CGI* only, if
> that's the trigger for it to do the desired thing, this won't be used
> by httpd internally at least.
>
> What's proposed so far is much more than that (if I read the patches 
> correctly).

Well, another proposal that wasn't in the patches, but was discussed
in bugzilla was to decouple mod_rewrite's HTTPS check from calling
mod_ssl directly and make it just check the environment variable, so
that rewrite conditions relying on it will still work behind a proxy.

Re: svn commit: r1707087 - /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c

[Jacob Champion]

On 10/06/2015 09:30 AM, yla...@apache.org wrote:

Author: ylavic
Date: Tue Oct  6 16:30:53 2015
New Revision: 1707087

URL: http://svn.apache.org/viewvc?rev=1707087=rev
Log:
mod_bucketeer: cleanup properly on EOS and write.


Hey Yann,

I've started testing reallyall builds of trunk, which are currently 
segfaulting in the middle of mod_info tests. A bisect points to this 
commit to mod_bucketeer, back in 2015. Reverting it makes everything run 
smoothly.


Any idea what's going wrong? Seems like mod_bucketeer is messing with 
the brigade in a way mod_info doesn't expect.


--Jacob



Modified:
httpd/httpd/trunk/modules/debugging/mod_bucketeer.c

Modified: httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/debugging/mod_bucketeer.c?rev=1707087=1707086=1707087=diff
==
--- httpd/httpd/trunk/modules/debugging/mod_bucketeer.c (original)
+++ httpd/httpd/trunk/modules/debugging/mod_bucketeer.c Tue Oct  6 16:30:53 2015
@@ -95,6 +95,7 @@ static apr_status_t bucketeer_out_filter
 /* Okay, we've seen the EOS.
  * Time to pass it along down the chain.
  */
+ap_remove_output_filter(f);
 return ap_pass_brigade(f->next, ctx->bb);
 }

@@ -145,6 +146,7 @@ static apr_status_t bucketeer_out_filter
 if (rv) {
 return rv;
 }
+apr_brigade_cleanup(ctx->bb);
 }
 }
 }

Re: mood_remoteip ProxyProtocol addition

[Jordan Gigov]

On 7 February 2017 at 18:08, Sander Hoentjen  wrote:
> Hi guys,
>
> I am trying to have haproxy added in front of our Apache servers, for
> SSL termination. This is not hard to do, and especially with the recent
> addition of ProxyProtocol support to mod_remoteip it works almost as we
> need it.
> Unfortunately we have a lot of users that use things like:
> RewriteCond %{HTTPS} !on
> in their .htaccess, and stuff like:
> if $_SERVER['HTTPS']
> in their PHP code.
>
> Long story short, I need httpd to act like SSL is on, if the haproxy
> instance says it is.
> Fortunately the proxy protocol supports this, and haproxy can send it.
> I have created a patch [1] that adds support for reading this in httpd,
> but I have never before done something with the httpd source code. And,
> as a matter of fact, have never really programmed in C before.
>
> I am hoping you would be willing to have a look at it and tell me all
> the things I am doing wrong. Eventually it would be awesome if the code
> could be added to apache itself.
>
> [1] https://github.com/AntagonistHQ/httpd/tree/remote-ssl
>
> Kind regards,
> Sander Hoentjen

I submitted an issue and a patch for that some time ago.

https://bz.apache.org/bugzilla/show_bug.cgi?id=59829

Recently updated it to the 2.5 trunk version, but it does not respect
the new ProxyProtocol stuff, which frankly I know nothing about.
It only works for the older proxy method.