AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Dienstag, 25. Juni 2019 13:59
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Tue, Jun 25, 2019 at 09:06:42AM +, Plüm, Rüdiger, Vodafone Group
> wrote:
> > > On Tue, Jun 25, 2019 at 08:49:08AM +0100, Joe Orton wrote:
> > > > Unless I am missing something the apr_dir_open/apr_dir_read API
> design
> > > > is always going to have memory use proportional to directory size
> > > > because apr_dir_read() duplicates the filename into the
> directory's
> > > > pool.  We need an apr_dir_pread() or whatever which takes a pool
> > > > argument. :(
> > >
> > > OK, yes, this plus an iterpool in dav_fs_walker() fixes it.
> >
> > Only the iterpool in dav_fs_walker or plus the changes in APR
> (apr_dir_pread)?
> 
> Yes, both - PoC attached but I'm not at all confident this is safe, esp
> in the recursion case.
> 
> The test I was running before was only a "core" liveprop provided by
> mod_dav itself, so I also tested the deadprops case and that still seems
> to leak.  sbrk() to increase the heap is getting triggered by
> apr_sdbm_open() every time I saw it, but apr_dbm_open() is being pass
> the scratchpool so I think it's not the cause.

I would agree, but can you please provide the stacktrace up to sbrk?
That would ease it for me to dive in :-).

> 
> Running "dump_all_pools propdb->p" at this point gives me:
> 
>Pool 'transaction' [0x24e1d88]: 7264/8192 free (1 blocks) allocator:
> 0x24d2b90 free blocks in allocator: 0 kiB
>  Pool 'master_conn' [0x2504e28]: 1224/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>Pool 'deferred_pool' [0x263ef18]: 8032/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>  Pool 'request' [0x2506e38]: 13672/1646592 free (201 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>Pool 'mod_dav_fs-walker' [0x2524648]: 8016/8192 free (1
> blocks) allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>Pool 'mod_dav-scratch' [0x2508e48]: 7224/8192 free (1 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
>Pool 'mod_lua-vm' [0x250ce68]: 6360/16384 free (2 blocks)
> allocator: 0x24d2b90 free blocks in allocator: 0 kiB
> 
> [trimmed some whitespace only]
> 
> I think this is implicating misuse of r->pool, that's grown rather
> large?
> 

I would think so as well.

Regards

Rüdiger

AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Dienstag, 25. Juni 2019 10:45
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Tue, Jun 25, 2019 at 08:49:08AM +0100, Joe Orton wrote:
> > Unless I am missing something the apr_dir_open/apr_dir_read API design
> > is always going to have memory use proportional to directory size
> > because apr_dir_read() duplicates the filename into the directory's
> > pool.  We need an apr_dir_pread() or whatever which takes a pool
> > argument. :(
> 
> OK, yes, this plus an iterpool in dav_fs_walker() fixes it.

Only the iterpool in dav_fs_walker or plus the changes in APR (apr_dir_pread)?

> 
> I've been using the python "psrecord" (from pip) to check this rather
> than my traditional method of "eyeballing top", here are the charts for
> running 10x a PROPFIND with ~100K files, for

Great plots. Thanks for pointing to the tool.

> 
> a) trunk - steep gradient, ~20mb consumed
> b) trunk plus the patch from my previous post, ~5mb?
> c) (b) plus iterpool in dav_fs_walker - flat
> 
> so I think (b) is fine to commit but with the recursion in dav_fs_walker
> I am not at all sure this stuff is safe yet, will need some more
> testing.

The recursion stuff could be tricky. Probably a separate (sub-)pool for 
apr_dir_open
on each recursion level and separate iterpools on each recursion level?

Regards

Rüdiger

AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Dienstag, 25. Juni 2019 09:49
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Mon, Jun 24, 2019 at 09:54:21PM +0200, Ruediger Pluem wrote:
> > On 06/24/2019 07:04 PM, Joe Orton wrote:
> > > #11 0x7f8110ce6448 in dav_do_prop_subreq (propdb=0x100cfc0) at
> props.c:331
> >
> > What if you go here and do a
> >
> > dump_all_pools propdb->p
> >
> > and do it again when you hit the next sbrk and the next one and so on?
> Something suspicious?
> 
> Well I did this and immediately noticed something suspicious on the
> previous line, e_uri is allocated from resource->pool (=r->pool) rather
> than propbb->p, so, yet again the precision accuracy of your insights is

Very good catch. Great that you found it.

> beyond belief Ruediger :) :)
> 
> This fixed a significant leak, but r->pool is still growing.  I think
> the remaining problem is use of r->pool in dav_fs_walker, i.e. is
> mod_dav_fs specific.

Do you think it is now good enough to commit at least as a first step?

> 
> Unless I am missing something the apr_dir_open/apr_dir_read API design
> is always going to have memory use proportional to directory size
> because apr_dir_read() duplicates the filename into the directory's
> pool.  We need an apr_dir_pread() or whatever which takes a pool
> argument. :(

In order to fix this leak, I agree that we would need this.
The pool is also used for apr_stat inside apr_dir_read, but I fail to see
how it consumes memory.

Another related question: Do you think it would be beneficial if we replace
the apr_psprintf with apr_pstrcat in props.c as long as they only concat 
strings without
further formatting?


Regards

Rüdiger

Questions with mod_proxy_http2

[Plüm , Rüdiger , Vodafone Group]

I recently started using mod_proxy_http2 and some questions popped up for me:

1. Why do we retry 5 times hardcoded (leading to AH10023 in case we fail)?
   The other protocols only try to retry once if the ping failed (additional 
Expect 100 header in the HTTP case, PING packet in the AJP case).
2. Could we try to leverage the ping configuration parameter for workers used 
by HTTP / AJP by sending a PING frame on the HTTP/2 backend
   connection and wait for the reply for the configured seconds in ping, retry 
once if failed with a new connection and return 503 if failed again
   or continue processing if things were fine?

Regards

Rüdiger

C2 General

AW: eor bucket

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 9. Mai 2019 12:00
> An: httpd-dev 
> Betreff: Re: eor bucket
> 
> On Thu, May 9, 2019 at 11:54 AM Yann Ylavic 
> wrote:
> >
> > On Thu, May 9, 2019 at 11:37 AM Stefan Eissing
> >  wrote:
> > >
> > > > Am 09.05.2019 um 11:32 schrieb Yann Ylavic :
> > > >
> > > > The issue is more that the hooks in eor_bucket_cleanup() will be
> run
> > > > multiple times, rather than a lifetime issue.
> > >
> > > I read it like this:
> > > The cleanup is only registered on the first creation. The copy never
> registers. But the bucket_destroy calls the pool destroy each time.
> >
> > Ah yes, apr_bucket_copy() (i.e. apr_bucket_simple_copy()) won't do the
> > right thing for eor, there should be an eor_bucket_copy() to register
> > the cleanup for the copy too.
> >
> > We should also possibly split the eor cleanup in two, one (registered
> > first) to run the hooks, and the second for NULLing b->data.
> > Both (but mainly the first one) would do nothing is b->data is already
> > NULL. That way I think the eor can be safely copied.
> 
> Or, use the EOR bucket code from trunk...

Which is the MMAP/file pattern approach as I just noticed :-) Thanks for the 
pointer.

Regards

Rüdiger

AW: eor bucket

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 9. Mai 2019 11:54
> An: httpd-dev 
> Betreff: Re: eor bucket
> 
> On Thu, May 9, 2019 at 11:37 AM Stefan Eissing
>  wrote:
> >
> > > Am 09.05.2019 um 11:32 schrieb Yann Ylavic :
> > >
> > > The issue is more that the hooks in eor_bucket_cleanup() will be run
> > > multiple times, rather than a lifetime issue.
> >
> > I read it like this:
> > The cleanup is only registered on the first creation. The copy never
> registers. But the bucket_destroy calls the pool destroy each time.
> 
> Ah yes, apr_bucket_copy() (i.e. apr_bucket_simple_copy()) won't do the
> right thing for eor, there should be an eor_bucket_copy() to register
> the cleanup for the copy too.
> 
> We should also possibly split the eor cleanup in two, one (registered
> first) to run the hooks, and the second for NULLing b->data.
> Both (but mainly the first one) would do nothing is b->data is already
> NULL. That way I think the eor can be safely copied.

I think we should follow a similar design pattern as we do with MMAP/file 
buckets which use a refcount.

Regards

Rüdiger

AW: eor bucket

[Plüm , Rüdiger , Vodafone Group]

I think your understanding is correct.

Regards

Rüdiger


C2 General

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Donnerstag, 9. Mai 2019 11:02
> An: dev@httpd.apache.org
> Betreff: eor bucket
> 
> Could someone help me to check my understanding of the eor bucket
> implementation?
> 
> If an eor bucket is ever copied, there are 2 buckets with their b->data
> pointing to the request_rec. Since this is local to the bucket,
> destroying these 2 will call apr_pool_destroy() twice on the pool.
> Correct?
> 
> -Stefan

AW: svn commit: r1787606 - /httpd/httpd/trunk/server/core.c

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Christophe JAILLET 
> Gesendet: Samstag, 4. Mai 2019 09:20
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1787606 - /httpd/httpd/trunk/server/core.c
> 
> Hi,
> 
> In my perpetual effort to synch 2.4 and trunk, I have stopped r1787606
> as a potential candidate.
> 
> However, I don't understand the rational with this patch and wonder if
> it should be backported, left as-is in trunk only or removed from trunk.
> 
> Why should we avoid timeout and TCP_NODELAY settings for slave
> connection?

Because to my understanding these are only 'logical' connections that share the
masters TCP connection.

> Is it already set some other way, (i.e APR_TCP_NODELAY_INHERITED???)

IMHO on the master connection.

> 
> 
> This patch also makes the 'if (c->master == NULL) {' block at the end of
> this function unclear.
> Now, we know that c->master != NULL and the logic could be simplified.

I agree that the c->master == NULL could be removed. I guess this could then be
backported together with r1787606.

Regards

Rüdiger

> 
> 
> Any opinion?
> 
> CJ
> 
> 
> Le 19/03/2017 à 11:33, ic...@apache.org a écrit :
> > Author: icing
> > Date: Sun Mar 19 10:33:43 2017
> > New Revision: 1787606
> >
> > URL: http://svn.apache.org/viewvc?rev=1787606=rev
> > Log:
> > On the trunk:
> >
> > core: avoid socket timeout settings etc. on slave connections.
> >
> >
> > Modified:
> >  httpd/httpd/trunk/server/core.c
> >
> > Modified: httpd/httpd/trunk/server/core.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/core.c?rev=1787606
> =1787605=1787606=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/server/core.c (original)
> > +++ httpd/httpd/trunk/server/core.c Sun Mar 19 10:33:43 2017
> > @@ -5280,9 +5280,14 @@ static conn_rec *core_create_conn(apr_po
> >
> >   static int core_pre_connection(conn_rec *c, void *csd)
> >   {
> > -core_net_rec *net = apr_palloc(c->pool, sizeof(*net));
> > +core_net_rec *net;
> >   apr_status_t rv;
> >
> > +if (c->master) {
> > +return DONE;
> > +}
> > +
> > +net = apr_palloc(c->pool, sizeof(*net));
> >   /* The Nagle algorithm says that we should delay sending partial
> >* packets in hopes of getting more data.  We don't want to do
> >* this; we are not telnet.  There are bad interactions between
> >
> >
> >

AW: keep-alive and vary in 304 responses

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Mittwoch, 10. April 2019 14:40
> An: dev@httpd.apache.org
> Betreff: Re: keep-alive and vary in 304 responses
> 
> 
> 
> > Am 10.04.2019 um 14:07 schrieb Plüm, Rüdiger, Vodafone Group
> :
> >
> >
> >
> >
> > C2 General
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Yann Ylavic 
> >> Gesendet: Mittwoch, 10. April 2019 14:04
> >> An: httpd-dev 
> >> Betreff: Re: keep-alive and vary in 304 responses
> >>
> >> On Wed, Apr 10, 2019 at 1:03 PM Plüm, Rüdiger, Vodafone Group
> >>  wrote:
> >>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: Yann Ylavic 
> >>>> Gesendet: Mittwoch, 10. April 2019 12:49
> >>>>
> >>>> Do user-agents support "Transfer-Encoding: gzip, chunked"
> currently?
> >>>> That'd be the best/easier solution I think.
> >>>
> >>> But TE is only hop-by-hop isn't it?. This would mean no e2e
> >> compression?
> >>
> >> A proxy can still forward hop-by-hop things, e.g. mod_proxy forwards
> >> "chunked" encoding if no previous handler/input-filter reads the
> body.
> >
> > My understanding was that mod_proxy "dechunks" the body and "chunks"
> it again.
> > It does not pass it transparently.
> > This would be a resource intensive job with compression.
> 
> I believe that a proxy could de-chunk without removing the gzip.

Not sure about this. I guess with TE each hop could be different in what it 
accepts
and generates. This is different from CE. As far as I understand the 
accept-encoding header
is only for CE not for TE.

> But how would our output filter infrastructure treat that? mod_deflate
> stays inactive when faced with an existing Content-Encoding, but does
> not
> watch out for Transfer-Encodings already applied. No resource type
> output
> filter does, right?

Right.

Regards

Rüdiger

AW: keep-alive and vary in 304 responses

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Mittwoch, 10. April 2019 14:04
> An: httpd-dev 
> Betreff: Re: keep-alive and vary in 304 responses
> 
> On Wed, Apr 10, 2019 at 1:03 PM Plüm, Rüdiger, Vodafone Group
>  wrote:
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Yann Ylavic 
> > > Gesendet: Mittwoch, 10. April 2019 12:49
> > >
> > > Do user-agents support "Transfer-Encoding: gzip, chunked" currently?
> > > That'd be the best/easier solution I think.
> >
> > But TE is only hop-by-hop isn't it?. This would mean no e2e
> compression?
> 
> A proxy can still forward hop-by-hop things, e.g. mod_proxy forwards
> "chunked" encoding if no previous handler/input-filter reads the body.

My understanding was that mod_proxy "dechunks" the body and "chunks" it again.
It does not pass it transparently.
This would be a resource intensive job with compression.

Regards

Rüdiger

AW: keep-alive and vary in 304 responses

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Mittwoch, 10. April 2019 12:49
> An: httpd-dev 
> Betreff: Re: keep-alive and vary in 304 responses
> 
> On Wed, Apr 10, 2019 at 12:10 PM Stefan Eissing
>  wrote:
> >
> > > Am 09.04.2019 um 18:48 schrieb Roy T. Fielding :
> > >>
> > >> 2. Validation responses lose the "Vary" header from the
> unconditional response. This happens on resources where mod_deflate is
> active.
> > >>  The 200 response without any "if-modified-since" etc. carries
> "Vary: Accept-Encoding" as it should.
> > >>  The 304 response with "if-modified-since" has no "Vary" header.
> > >>  The code in mod_deflate looks as if it tries to add it in any
> case, where is it lost?
> > >
> > > That's one of many bugs related to design problems with mod_deflate.
> Basically,
> > > it chooses to insert itself into the response handling after the
> other checks are done,
> > > which means a 304 doesn't even know yet whether the response would
> use gzip.
> > > The solution (which I never found time to implement) is to replace
> dynamic gzip with
> > > a transfer encoding generator,
> 
> Do user-agents support "Transfer-Encoding: gzip, chunked" currently?
> That'd be the best/easier solution I think.

But TE is only hop-by-hop isn't it?. This would mean no e2e compression?
Also we need to keep in mind similar issues for similar filters e.g. mod_brotli

Regards

Rüdiger

AW: keep-alive and vary in 304 responses

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Mittwoch, 10. April 2019 12:10
> An: dev@httpd.apache.org
> Betreff: Re: keep-alive and vary in 304 responses
> 
> 
> > Am 09.04.2019 um 18:48 schrieb Roy T. Fielding :
> >
> >>
> >> 2. Validation responses lose the "Vary" header from the unconditional
> response. This happens on resources where mod_deflate is active.
> >>  The 200 response without any "if-modified-since" etc. carries "Vary:
> Accept-Encoding" as it should.
> >>  The 304 response with "if-modified-since" has no "Vary" header.
> >>  The code in mod_deflate looks as if it tries to add it in any case,
> where is it lost?
> >
> > That's one of many bugs related to design problems with mod_deflate.
> Basically,
> > it chooses to insert itself into the response handling after the other
> checks are done,
> > which means a 304 doesn't even know yet whether the response would use
> gzip.
> > The solution (which I never found time to implement) is to replace
> dynamic gzip with
> > a transfer encoding generator, and/or to rewrite the mod_deflate CE
> encoder to act more
> > like mod_cache.
> 
> Thinking out loud here:
> 
> Acting more like mod_cache would then split the deflate output filter
> into a resource and a protocol type one, I assume?

IMHO the "secret" of mod_cache is that its filter is also inserted via the
insert_error_filter hook and not just via the insert_filter hook (like 
mod_expires and mod_header do).
With mod_deflate this will be more complex as mod_deflate does not add itself.
It is either added by the core via SetOuputFilter or via mod_filter and they
all only consider insert_filter and not insert_error_filter. We probably need
a possibility to tell filters to be added in insert_error_filter.

Regards

Rüdiger

AW: [VOTE] Release httpd-2.4.39

[Plüm , Rüdiger , Vodafone Group]

What pcre lib did you use on CentOS5? The one provided by CentOS or your own?

Regards

Rüdiger



C2 General
Von: Jim Jagielski 
Gesendet: Donnerstag, 28. März 2019 14:52
An: httpd 
Betreff: Re: [VOTE] Release httpd-2.4.39

Yep, CentOS5. Mostly due to the fact that regressions would likely show up more 
readily on older OSs rather than newer ones.

Plus, there's still a crap-ton of systems using CentOS5/RHEL5

On Mar 28, 2019, at 8:51 AM, Plüm, Rüdiger, Vodafone Group 
mailto:ruediger.pl...@vodafone.com>> wrote:




C2 General

-Ursprüngliche Nachricht-
Von: Jim Jagielski mailto:j...@jagunet.com>>
Gesendet: Donnerstag, 28. März 2019 13:39
An: httpd mailto:dev@httpd.apache.org>>
Betreff: Re: [VOTE] Release httpd-2.4.39


On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri 
mailto:drugg...@primary.net>>
wrote:

Hi, all;
 Please find below the proposed release tarball and signatures:
https://dist.apache.org/repos/dist/dev/httpd/

I would like to call a VOTE over the next few days to release this
candidate tarball as 2.4.39:
[ ] +1: It's not just good, it's good enough!
[ ] +0: Let's have a talk.
[ ] -1: There's trouble in paradise. Here's what's wrong.

The computed digests of the tarball up for vote are:
sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
sha256:
8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
2.4.39.tar.gz

--
Daniel Ruggeri

Tested and passed on the following systems (no regressions):

 o macOS 10.14.4, Xcode 10.2
 o CentOS 5, 64bit

Really CentOS 5? Just asking because it does not receive further OS updates and 
I wouldn't recommend to use it any longer.

Regards

Rüdiger

AW: AW: [VOTE] Release httpd-2.4.39

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Dennis Clarke 
> Gesendet: Donnerstag, 28. März 2019 14:23
> An: dev@httpd.apache.org
> Betreff: Re: AW: [VOTE] Release httpd-2.4.39
> 
> On 3/28/19 8:51 AM, Plüm, Rüdiger, Vodafone Group wrote:
> >
> >
> >
> >>
> >> Tested and passed on the following systems (no regressions):
> >>
> >>   o macOS 10.14.4, Xcode 10.2
> >>   o CentOS 5, 64bit
> >
> > Really CentOS 5? Just asking because it does not receive further OS
> updates and I wouldn't recommend to use it any longer.
> >
> 
> People out there are running all manner of boxen and that even includes
> Solaris 10 or maybe some variation of SCO UNIX. Anything can and will
> happen. I am certain that there are CentOS 5/RHEL5 boxen out there just
> churning away and doing what they do for the last decade or so.

I am sure as well, but the question is: Is it worth testing on these platforms 
still
and thus encourage people to still use them?
I remember that I faced an issue with CentOS 5 and the system supplied pcre and 
2.4.
Hence I was also wondering how that passed. Possibly an external pcre.

Regards

Rüdiger

AW: [VOTE] Release httpd-2.4.39

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski 
> Gesendet: Donnerstag, 28. März 2019 13:39
> An: httpd 
> Betreff: Re: [VOTE] Release httpd-2.4.39
> 
> 
> > On Mar 27, 2019, at 11:09 AM, Daniel Ruggeri 
> wrote:
> >
> > Hi, all;
> >   Please find below the proposed release tarball and signatures:
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a VOTE over the next few days to release this
> candidate tarball as 2.4.39:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
> >
> > The computed digests of the tarball up for vote are:
> > sha1: e66d6bfea42254e64d3b5009f49ecc486ac46de2 *httpd-2.4.39.tar.gz
> > sha256:
> 8b95fe249f3a6c50aad3ca125eef3e02d619116cde242e1bc3c266b7b5c37c30 *httpd-
> 2.4.39.tar.gz
> >
> > --
> > Daniel Ruggeri
> 
> Tested and passed on the following systems (no regressions):
> 
>   o macOS 10.14.4, Xcode 10.2
>   o CentOS 5, 64bit

Really CentOS 5? Just asking because it does not receive further OS updates and 
I wouldn't recommend to use it any longer.

Regards

Rüdiger

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

[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.

AW: svn commit: r1850745 - /httpd/httpd/trunk/modules/filters/config.m4

[Plüm , Rüdiger , Vodafone Group]

C2 General

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Mittwoch, 16. Januar 2019 10:00
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1850745 -
> /httpd/httpd/trunk/modules/filters/config.m4
> 
> 
> 
> > Am 16.01.2019 um 03:33 schrieb William A Rowe Jr  clan.net>:
> >
> > On Tue, Jan 15, 2019 at 8:37 AM Jim Jagielski  wrote:
> >
> > > On Jan 15, 2019, at 9:21 AM, Eric Covener  wrote:
> > >
> > > On Tue, Jan 15, 2019 at 9:14 AM Jim Jagielski 
> wrote:
> > >>
> > >> On Jan 9, 2019, at 7:41 PM, William A Rowe Jr 
> wrote:
> > >>
> > >> Hi Jim,
> > >>
> > >> Does CFLAGS -std=c99 solve your issue? It seems to work here. I'm
> building on the Fedora 29, largely frozen end-of-july. Reverting the
> patch below and toggling -std=c89 to -std=c99 in configure.in building
> all but two modules from trunk is building clean, and results in this
> command for error checking;
> > >> /usr/lib64/apr-1/build/libtool --silent --mode=compile gcc  -
> pthread -std=c99 -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes
> -Wmissing-declarations -Wdeclaration-after-statement -Wpointer-arith -
> Wformat -Wformat-security -Wunused -DLINUX -D_REENTRANT -
> D_GNU_SOURCE -DAP_DEBUG
> > >>
> > >> Is it reasonable to enforce c99 limitations at this late date? I'm
> not suggesting we change the general builds from c89 in the 2.4 branch,
> but that is something we might want to consider for trunk, 20 years out.
> > >>
> > >>
> > >> Personally, I'd be fine allowing c99 in both 2.4 and trunk,
> considering that we are in 2019 already :)
> > >>
> > >> Any platform that lacks a c99 compatible CC likely doesn't build
> anyway.
> > >
> > > As a binary distributor, even though a C99 compiler may be available
> > > on platform X, it might not be in use.  Wouldn't love seeing it in
> > > 2.4.
> >
> > I'm not proposing a change for 2.4... but I wouldn't oppose it either
> :)
> >
> > Allowing c99 for trunk would make backporting to 2.4 (which would stay
> c89) possibly more difficult. This is either a good thing or a bad
> thing. So far, however, iirc we have not had any issues sticking with
> c89 and I don't think the above would warrant such a change. IMO of
> course.
> >
> > I might not have been clear, above. I'm not suggesting changing things
> for the
> > customary build, leave that (at least on httpd 2.4) as -std=c89. I
> think we should
> > have this discussion of when we will begin accepting c99 source
> patches, but
> > that isn't the immediate problem you've tripped over.
> >
> > I see several options;
> >
> >   Only for maintainer mode, where we are strictly handling all errors,
> always
> >   accept all -std=c99 behaviors (fix any legacy pre-c99 issues that
> may arise.)
> >   All the system headers using c99 (or earlier) semantics should
> behave well.
> >
> >   Or, for maintainer mode, always relax the comments restriction only
> so we
> >   have -std=c89 -Werror -Wall -Wno-error=comment (but not modified in
> the
> >   modules/filters/config.m4 where it isn't apparent who toggled this.)
> You can
> >   almost call this c99-lite which solves one c99'ism in newer system
> headers
> >   without allowing all the c99'isms in system headers.
> >
> >   Or, staying closest to the proposed patch, add -Wno-error=comment
> only
> >   to mod_proxy_html's CPPFLAGS, and stop messing with the rest of the
> >   compilation for a single module.
> >
> > In every case, I'm expecting we still adhere to c89, especially in
> httpd-2.4
> > branch. A typical compilation (non-maintainer-mode) should catch most
> > of those irregularities.
> 
> My pov:
> - as long as 2.4.x is our only release branch, I'd like trunk maintainer
> mode to stay compatible
> - I would like to switch to c99 as soon as 2.6.0 is out
> - The CPPFLAGS switch for the module only seems to be the least
> intrusive

Sounds sensible.

Regards

Rüdiger

AW: Plan to add sandbox branch

[Plüm , Rüdiger , Vodafone Group]

Just a quick and dirty idea and nothing beyond that worked out: How about to 
allow the balancer members to be configured via DNS SRV records? That should be 
very common in container environments.

Regards

Rüdiger

Von: Christophe JAILLET 
Gesendet: Donnerstag, 29. November 2018 07:03
An: dev@httpd.apache.org
Betreff: Re: Plan to add sandbox branch

Le 28/11/2018 à 02:33, Daniel Ruggeri a écrit :

Hi, Jim;
I'm coming up empty on a search against the Google-machine for SURVEY protocol. 
Any pointers you can share?
Hi

Not sure if the answers already posted are what you are looking for.
Here are some links:
   https://nanomsg.org/gettingstarted/survey.html and other resources on 
https://nanomsg.org/


CJ

AW: ap_request_core_filter issues

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Dienstag, 23. Oktober 2018 13:09
> An: httpd-dev 
> Betreff: Re: ap_request_core_filter issues
> 
> On Thu, Oct 18, 2018 at 1:52 PM Joe Orton  wrote:
> >
> > On Thu, Oct 18, 2018 at 12:51:06PM +0200, Ruediger Pluem wrote:
> > > >>>
> > > >>> Curiously inefficient writev use when stracing the process,
> though,
> > > >>> dunno what's going on there (trunk/prefork):
> > > >>>
> > > >>> writev(46, [{iov_base="\r\n", iov_len=2}], 1) = 2
> > > >>> writev(46, [{iov_base="1f84\r\n", iov_len=6}], 1) = 6
> > > >>> writev(46, [{iov_base="\n iov_len=7820}], 1) = 7820
> > > >>> writev(46, [{iov_base="\n\n"...,
> iov_len=248}], 1) = 248
> > > >>
> > > >> The reason is ap_request_core_filter. It iterates over the
> brigade and hands over each bucket alone to
> > > >> ap_core_output_filter. IMHO a bug.
> > > >
> > > > How about the attached patch for fixing?
> > >
> > > Scratch that. I guess it is much more complex.
> >
> > Hmm, well it works for me and looks correct, it batches up those the
> > writev(,,1) calls as expected, but it seems YMMV :)
> 
> After a closer look into this, Rüdiger's patch seems indeed incomplete.
> What we possibly want is keep buckets in tmp_bb until it's time to
> pass it down the chain, per ap_filter_reinstate_brigade() logic (i.e.
> FLUSH bucket, size limit, ...).
> 
> I tried to implement that in the attached patch, WDYT?

1. Why removing the META_BUCKET check when reading buckets of length -1? I 
don't see any sense in
   doing an apr_bucket_read on a META_BUCKET.
2. Apart from 1. I think the flow is correct, but I am a little bit worried if 
calling ap_filter_reinstate_brigade
   inside the loop iterating over the brigade has a too large performance 
impact as ap_filter_reinstate_brigade
   iterates itself over the brigade. So we are in O(n^2) with n being the size 
of the brigade. But to be honest I have
   no good idea yet how to do without. The only thing I can think of is to 
duplicate and merge the logic of ap_filter_reinstate_brigade
   inside our loop to avoid this as we could gather the stats needed for 
deciding up to which bucket we need to write while
   doing our iteration of the brigade.


Regards

Rüdiger

AW: AW: [VOTE] Release httpd-2.4.36

[Plüm , Rüdiger , Vodafone Group]

Do you know if the failure is a regression over 2.4.35?

Regards

Rüdiger

Von: Marion et Christophe JAILLET 
Gesendet: Donnerstag, 11. Oktober 2018 13:13
An: dev@httpd.apache.org
Betreff: re: AW: [VOTE] Release httpd-2.4.36


Waouh!



This would mean I've provided a new useful test!

(it has been added recently in r1841508)



:)



I definitely need to document how to generate and use test-coverage data when 
running the test framework.

This helps to spot where new tests are needed.



CJ






> Message du 11/10/18 10:08
> De : "Plüm, Rüdiger, Vodafone Group" 
> mailto:ruediger.pl...@vodafone.com>>
> A : "dev@httpd.apache.org<mailto:dev@httpd.apache.org>" 
> mailto:dev@httpd.apache.org>>
> Copie à :
> Objet : AW: [VOTE] Release httpd-2.4.36
>
> Anyone else seeing
>
> t/modules/buffer.t (Wstat: 0 Tests: 12 Failed: 2)
> Failed tests: 8, 12
>
> ?
>
> I don't see this with trunk on the same machine. Issue seems to be if input 
> filtering is on on large POSTs.
>
> Regards
>
> Rüdiger
>
> > -Ursprüngliche Nachricht-
> > Von: Daniel Ruggeri mailto:drugg...@primary.net>>
> > Gesendet: Donnerstag, 11. Oktober 2018 02:27
> > An: dev@httpd.apache.org<mailto:dev@httpd.apache.org>
> > Betreff: Re: [VOTE] Release httpd-2.4.36
> >
> > +1 from me (talking to myself).
> >
> > Test environment follows. I observe only one failure of the test suite
> > (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> >
> > system:
> >   kernel:
> > name: Linux
> > release: 3.16.0-4-amd64
> > version: #1 SMP Debian 3.16.51-3 (2017-12-13)
> > machine: x86_64
> >
> >   libraries:
> > openssl: "1.1.1"
> > openldap: "2.4.46"
> > apr: "1.6.5"
> > apr-util: "1.6.1"
> > iconv: "1.2.2"
> > brotli: "1.0.6"
> > nghttp2: "1.34.0"
> > zlib: "1.2.11"
> > pcre: "8.42"
> > libxml2: "2.9.8"
> > php: "5.6.38"
> > lua: "5.3.5"
> > curl: "7.61.1"
> >
> > --
> > Daniel Ruggeri
> >
> > On 10/10/2018 2:18 PM, Daniel Ruggeri wrote:
> > > Hi, all;
> > >Please find below the proposed release tarball and signatures:
> > > https://dist.apache.org/repos/dist/dev/httpd/
> > >
> > > I would like to call a VOTE over the next few days to release this
> > > candidate tarball as 2.4.36:
> > > [ ] +1: It's not just good, it's good enough!
> > > [ ] +0: Let's have a talk.
> > > [ ] -1: There's trouble in paradise. Here's what's wrong.
> > >
> > > The computed digests of the tarball up for vote are:
> > > sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> > > sha256:
> > > ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> > > *httpd-2.4.36.tar.gz
> > >
>
>

AW: [VOTE] Release httpd-2.4.36

[Plüm , Rüdiger , Vodafone Group]

Anyone else seeing

t/modules/buffer.t(Wstat: 0 Tests: 12 Failed: 2)
  Failed tests:  8, 12

?

I don't see this with trunk on the same machine. Issue seems to be if input 
filtering is on on large POSTs.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Daniel Ruggeri 
> Gesendet: Donnerstag, 11. Oktober 2018 02:27
> An: dev@httpd.apache.org
> Betreff: Re: [VOTE] Release httpd-2.4.36
> 
> +1 from me (talking to myself).
> 
> Test environment follows. I observe only one failure of the test suite
> (mentioned elsewhere) - it seems only to apply w/ OpenSSL 1.1.1 and H2.
> 
> system:
>   kernel:
>     name: Linux
>     release: 3.16.0-4-amd64
>     version: #1 SMP Debian 3.16.51-3 (2017-12-13)
>     machine: x86_64
> 
>   libraries:
>     openssl: "1.1.1"
>     openldap: "2.4.46"
>     apr: "1.6.5"
>     apr-util: "1.6.1"
>     iconv: "1.2.2"
>     brotli: "1.0.6"
>     nghttp2: "1.34.0"
>     zlib: "1.2.11"
>     pcre: "8.42"
>     libxml2: "2.9.8"
>     php: "5.6.38"
>     lua: "5.3.5"
>     curl: "7.61.1"
> 
> --
> Daniel Ruggeri
> 
> On 10/10/2018 2:18 PM, Daniel Ruggeri wrote:
> > Hi, all;
> >    Please find below the proposed release tarball and signatures:
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a VOTE over the next few days to release this
> > candidate tarball as 2.4.36:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
> >
> > The computed digests of the tarball up for vote are:
> > sha1: e40e7a879b84df860215b8a80f2a535534a1c4b4 *httpd-2.4.36.tar.gz
> > sha256:
> > ef788fb7c814acb2506a8b758a1a3f91f368f97bd4e6db16e98001f468e8e288
> > *httpd-2.4.36.tar.gz
> >

AW: svn commit: r1834924 - /httpd/httpd/branches/2.4.x/STATUS

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Graham Leggett 
> Gesendet: Mittwoch, 10. Oktober 2018 19:12
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1834924 - /httpd/httpd/branches/2.4.x/STATUS
> 
> On 28 Aug 2018, at 12:17, Ruediger Pluem  wrote:
> 
> >> On 07/20/2018 02:49 PM, Yann Ylavic wrote:
> >>> Ping, any objection if I commit this and add it to the backport
> proposal?
> >>
> >> Hmm. Looks like MODSSL_ERROR_BAD_GATEWAY is only used when the proxy
> connects to the backend.
> >> So the patch should be fine.
> >
> >
> > Do you want to commit and update the backport proposal?
> 
> Quick ping, are you happy with the updated proposal?

Fine now. r18843533

Regards

Rüdiger

AW: svn commit: r1842540 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_kernel.c

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Montag, 8. Oktober 2018 23:46
> An: httpd-dev 
> Betreff: Re: svn commit: r1842540 - in /httpd/httpd/trunk: CHANGES
> modules/ssl/ssl_engine_kernel.c
> 
> On Fri, Oct 5, 2018 at 12:49 PM Ruediger Pluem 
> wrote:
> >
> >
> >
> > On 10/05/2018 12:26 PM, Rainer Jung wrote:
> > > Shouldn't we backport this? Or do you have doubts or maybe waiting
> for feedback?
> >
> > From my point of view it can be backported. It was sitting around in
> trunk waiting for feedback and then because of
> > being busy I forgot about. Feel free to propose.
> 
> Proposed for backport in r1843208.
> Thanks for the fix Rüdiger.

Thanks for proposing.

Regards

Rüdiger

AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

r1842010

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Mittwoch, 26. September 2018 11:41
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Wed, Sep 26, 2018 at 09:30:25AM +, Plüm, Rüdiger, Vodafone Group
> wrote:
> > Thanks for reporting. Does the below patch cause the crash to go away?
> 
> Yes, works for me!

AW: svn commit: r1841225 - /httpd/httpd/trunk/modules/dav/main/props.c

[Plüm , Rüdiger , Vodafone Group]

Thanks for reporting. Does the below patch cause the crash to go away?

Index: main/mod_dav.c
===
--- main/mod_dav.c  (revision 1841799)
+++ main/mod_dav.c  (working copy)
@@ -2059,10 +2059,10 @@
  : DAV_PROP_INSERT_NAME;
 propstats = dav_get_allprops(propdb, what);
 }
+dav_stream_response(wres, 0, , ctx->scratchpool);
+
 dav_close_propdb(propdb);
 
-dav_stream_response(wres, 0, , ctx->scratchpool);
-
 /* at this point, ctx->scratchpool has been used to stream a
single response.  this function fully controls the pool, and
thus has the right to clear it for the next iteration of this

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Mittwoch, 26. September 2018 11:08
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1841225 -
> /httpd/httpd/trunk/modules/dav/main/props.c
> 
> On Tue, Sep 18, 2018 at 03:04:13PM +0200, Ruediger Pluem wrote:
> > Pools are very tricky in mod_dav. Hence additional eyeballs are very
> much welcome here.
> > As I only did testing with mod_dav_fs I would be keen to know if
> things still work with Subversion.
> > So if someone from the Subversion guys is listening here: Having this
> tested with Subversion would be very welcome :-).
> 
> Not reviewed sorry, but I saw a crash under APR with --enable-pool-debug
> when running t/modules/dav.t - the backtrace has the magic 0x41s which
> suggests pool-related:
> 
> #0  0x7f74e8deb7c1 in __strlen_avx2 () from /lib64/libc.so.6
> #1  0x7f74d3901093 in dav_send_one_response
> (response=0x7f747cff8650, bb=0x7f746c01f960, r=0x7f746c002230,
> pool=0x7f746c01f3e0) at mod_dav.c:491
> #2  0x7f74d39012e6 in dav_stream_response (status=0,
> wres=0x7f747cff8808, wres=0x7f747cff8808,
> pool=, propstats=) at
> mod_dav.c:1192
> #3  dav_propfind_walker (wres=0x7f747cff8808, calltype=)
> at mod_dav.c:2064
> #4  0x7f74d28c7f8c in dav_fs_walker
> (fsctx=fsctx@entry=0x7f747cff8800, depth=depth@entry=1) at repos.c:1759
> #5  0x7f74d28c852f in dav_fs_internal_walk (params=0x7f747cff8ad0,
> depth=1, is_move=0, root_dst=0x0,
> response=0x7f747cff8ac8) at repos.c:1844
> #6  0x7f74d3905b3e in dav_method_propfind (r=0x7f746c002230) at
> mod_dav.c:2190
> 
> ...
> (gdb) up
> #1  0x7f74d3901093 in dav_send_one_response
> (response=0x7f747cff8650, bb=0x7f746c01f960, r=0x7f746c002230,
> pool=0x7f746c01f3e0) at mod_dav.c:491
> 491   ap_fputs(r->output_filters, bb, t->text);
> (gdb) print t
> $1 = (apr_text *) 0x7f746c01dcc0
> (gdb) print *t
> $2 = {text = 0x0, next = 0x4141414141414141}
> 
> 
> >
> > Regards
> >
> > Rüdiger
> >
> > On 09/18/2018 02:58 PM, rpl...@apache.org wrote:
> > > Author: rpluem
> > > Date: Tue Sep 18 12:58:57 2018
> > > New Revision: 1841225
> > >
> > > URL: http://svn.apache.org/viewvc?rev=1841225=rev
> > > Log:
> > > * Doing a PROPFIND on a large collection e.g. 50.000 elements can
> easily
> > >   consume 1 GB of memory as the subrequests and propdb pools are not
> > >   destroyed and cleared after each element was handled.
> > >   Do this now. There is one case in dav_get_props where elem->priv
> > >   lives longer then the propdb pool. In this case allocate from r-
> >pool.
> > >   Furthermore also recycle propdb's which allows to clear the
> propdb's
> > >   pools instead of destroying them and creating them again.
> > >
> > > Modified:
> > > httpd/httpd/trunk/modules/dav/main/props.c
> > >
> > > Modified: httpd/httpd/trunk/modules/dav/main/props.c
> > > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/props.c?
> rev=1841225=1841224=1841225=diff
> > >
> 
> ==
> > > --- httpd/httpd/trunk/modules/dav/main/props.c (original)
> > > +++ httpd/httpd/trunk/modules/dav/main/props.c Tue Sep 18 12:58:57
> 2018
> > > @@ -524,7 +524,21 @@ DAV_DECLARE(dav_error *)dav_open_propdb(
> > >  apr_array_header_t *
> ns_xlate,
> > >  dav_propdb **p_propdb)
> > >  {
> > > -dav_propdb *propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> > > +dav_propdb *propdb = NULL;
> > > +/*
> > > + * Check if we have tucked away a previous propdb and reuse it.
> > > + * Otherwise create a new one and tuck it away
> > > + */
> > > +apr_pool_userdata_get((void **), "propdb", r->pool);
> > > +if (!propdb) {
> > > +propdb = apr_pcalloc(r->pool, sizeof(*propdb));
> > > +apr_pool_userdata_setn(propdb, "propdb", NULL, r->pool);
> > > +apr_pool_create(>p, r->pool);
> > > +}
> > > +else {
> > > +/* Play safe and clear the pool of the reused probdb */
> > > +apr_pool_clear(propdb->p);
> > > +}
> > >
> > >  *p_propdb = NULL;
> > >
> > > @@ -537,7 +551,6 @@ DAV_DECLARE(dav_error 

AW: minor nit in mod_ssl

[Plüm , Rüdiger , Vodafone Group]

Thanks.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Donnerstag, 20. September 2018 11:58
> An: dev@httpd.apache.org
> Betreff: Re: minor nit in mod_ssl
> 
> Fair enough. Done in r1841455.
> 
> > Am 20.09.2018 um 11:53 schrieb Plüm, Rüdiger, Vodafone Group
> :
> >
> > Correct, but the issue is that as an admin you do not always get the
> error page that a client sees and you have to search for the cause
> without.
> > Especially in this case as non SNI clients are often not browsers but
> non interactive programs.
> >
> > Regards
> >
> > Rüdiger
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Stefan Eissing 
> >> Gesendet: Donnerstag, 20. September 2018 11:46
> >> An: dev@httpd.apache.org
> >> Betreff: Re: minor nit in mod_ssl
> >>
> >> I am not opposed. However, there is an explanation added to the
> request
> >> error notes, which normally appears in the 403 response if I am not
> >> mistaken?
> >>
> >> -Stefan
> >>
> >>> Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group
> >> :
> >>>
> >>> Can we have set it to info? Debug is very verbose for SSL just to
> find
> >> out why a HTTP request was replied to with a 403.
> >>>
> >>> Regards
> >>>
> >>> Rüdiger
> >>>
> >>> Von: William A Rowe Jr 
> >>> Gesendet: Montag, 17. September 2018 22:27
> >>> An: httpd 
> >>> Betreff: Re: minor nit in mod_ssl
> >>>
> >>> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
> >>  wrote:
> >>>>
> >>>> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> >> strict_sni_vhost_check is enabled and a request comes in without SNI.
> >>>>
> >>>> Question: is a downgrade from ERR to INFO/DEBUG backportable or do
> >> we consider this a break of compatibility?
> >>>
> >>>
> >>>
> >>> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr  >> clan.net> wrote:
> >>>>
> >>>> It is entirely appropriate to turn down the volume. That's what
> >> module-by-module loglevels are there for.
> >>>
> >>>
> >>> This is the loglevel of typical garbage request streams;
> >>>
> >>> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid
> >> 140199172134656] protocol.c(965): (20014)Internal error (specific
> >> information not available): [client 127.0.0.1:34974] Failed to read
> >> request header line (null)
> >>> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid
> >> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567:
> >> request failed: error reading the headers
> >>> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid
> >> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418:
> HTTP
> >> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace
> was
> >> injected?)
> >>>
> >>> It seems that TLS missing SNI fits this same debug-level pattern of
> >> diagnostics.
> >

AW: minor nit in mod_ssl

[Plüm , Rüdiger , Vodafone Group]

Correct, but the issue is that as an admin you do not always get the error page 
that a client sees and you have to search for the cause without.
Especially in this case as non SNI clients are often not browsers but non 
interactive programs.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Donnerstag, 20. September 2018 11:46
> An: dev@httpd.apache.org
> Betreff: Re: minor nit in mod_ssl
> 
> I am not opposed. However, there is an explanation added to the request
> error notes, which normally appears in the 403 response if I am not
> mistaken?
> 
> -Stefan
> 
> > Am 20.09.2018 um 11:40 schrieb Plüm, Rüdiger, Vodafone Group
> :
> >
> > Can we have set it to info? Debug is very verbose for SSL just to find
> out why a HTTP request was replied to with a 403.
> >
> > Regards
> >
> > Rüdiger
> >
> > Von: William A Rowe Jr 
> > Gesendet: Montag, 17. September 2018 22:27
> > An: httpd 
> > Betreff: Re: minor nit in mod_ssl
> >
> > On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
>  wrote:
> > >
> > > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when
> strict_sni_vhost_check is enabled and a request comes in without SNI.
> > >
> > > Question: is a downgrade from ERR to INFO/DEBUG backportable or do
> we consider this a break of compatibility?
> >
> >
> >
> > On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr  clan.net> wrote:
> > >
> > > It is entirely appropriate to turn down the volume. That's what
> module-by-module loglevels are there for.
> >
> >
> > This is the loglevel of typical garbage request streams;
> >
> > [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(965): (20014)Internal error (specific
> information not available): [client 127.0.0.1:34974] Failed to read
> request header line (null)
> > [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid
> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567:
> request failed: error reading the headers
> > [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid
> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP
> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was
> injected?)
> >
> > It seems that TLS missing SNI fits this same debug-level pattern of
> diagnostics.

AW: minor nit in mod_ssl

[Plüm , Rüdiger , Vodafone Group]

Can we have set it to info? Debug is very verbose for SSL just to find out why 
a HTTP request was replied to with a 403.

Regards

Rüdiger

Von: William A Rowe Jr 
Gesendet: Montag, 17. September 2018 22:27
An: httpd 
Betreff: Re: minor nit in mod_ssl

On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing 
mailto:stefan.eiss...@greenbytes.de>> wrote:
>
> mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when 
> strict_sni_vhost_check is enabled and a request comes in without SNI.
>
> Question: is a downgrade from ERR to INFO/DEBUG backportable or do we 
> consider this a break of compatibility?



On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr 
mailto:wr...@rowe-clan.net>> wrote:
>
> It is entirely appropriate to turn down the volume. That's what 
> module-by-module loglevels are there for.


This is the loglevel of typical garbage request streams;

[Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 140199172134656] 
protocol.c(965): (20014)Internal error (specific information not available): 
[client 127.0.0.1:34974] Failed to read request header 
line (null)
[Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 140199172134656] 
protocol.c(1318): [client 127.0.0.1:34974] AH00567: 
request failed: error reading the headers
[Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 140199180527360] 
protocol.c(860): [client 127.0.0.1:35330] AH02418: HTTP 
Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was 
injected?)

It seems that TLS missing SNI fits this same debug-level pattern of diagnostics.

AW: async mod_proxy_http

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 13. September 2018 12:24
> An: httpd-dev 
> Betreff: Re: async mod_proxy_http
> 
> On Thu, Sep 13, 2018 at 10:55 AM Plüm, Rüdiger, Vodafone Group
>  wrote:
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Yann Ylavic 
> > > Gesendet: Donnerstag, 13. September 2018 10:37
> > > An: httpd-dev 
> > > Betreff: Re: async mod_proxy_http
> > >
> > > On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
> > >  wrote:
> > > >
> > > > I don't like the "misuse" of c->aborted here. I for instance log
> in
> > > > the access log whether connections have been aborted or not and
> this
> > > > approach would mean that all proxied websocket connections would
> get
> > > > marked as aborted. Can't we use any other flag to tell the MPM to
> > > > close the socket and push the pool, e.g. a note in c->notes?
> > > > Why is the lingering close no longer needed?
> > >
> > > Agreed, let lingering close do its job if the client connection is
> not
> > > closed already.
> > > Better in v2 (attached)?
> >
> > Better. Should a module outside the core directly fiddle around with
> > the connection state in this case setting it to CONN_STATE_LINGER?
> 
> I'd said no... but for modules playing async with the MPM :p
> One way or another we need a flag which is meant for the MPM at
> resume_suspended time (be it the state, a c->notes, ...), and that
> hook is likely to be called by modules going async...

So we lack some clearly defined API here?
If yes shouldn't one defined?

Regards

Rüdiger

AW: async mod_proxy_http

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 13. September 2018 10:37
> An: httpd-dev 
> Betreff: Re: async mod_proxy_http
> 
> On Thu, Sep 13, 2018 at 8:49 AM Plüm, Rüdiger, Vodafone Group
>  wrote:
> >
> > I don't like the "misuse" of c->aborted here. I for instance log in
> > the access log whether connections have been aborted or not and this
> > approach would mean that all proxied websocket connections would get
> > marked as aborted. Can't we use any other flag to tell the MPM to
> > close the socket and push the pool, e.g. a note in c->notes?
> > Why is the lingering close no longer needed?
> 
> Agreed, let lingering close do its job if the client connection is not
> closed already.
> Better in v2 (attached)?

Better. Should a module outside the core directly fiddle around with the 
connection state in this case setting it to CONN_STATE_LINGER?

> 
> > Why now doing ap_mpm_resume_suspended after
> > ap_finalize_request_protocol(baton->r) and
> > ap_process_request_after_handler(baton->r)?
> 
> I think we don't want EOS/EOR filtering race with the MPM on the
> connection...
> 

Fair enough.

Regards

Rüdiger

AW: async mod_proxy_http

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener 
> Gesendet: Donnerstag, 13. September 2018 02:34
> An: Apache HTTP Server Development List 
> Betreff: Re: async mod_proxy_http
> 
> On Wed, Sep 12, 2018 at 7:59 PM Yann Ylavic 
> wrote:
> >
> > On Wed, Sep 12, 2018 at 5:53 PM Eric Covener 
> wrote:
> > >
> > > Forking from the Cool Stuff thread.
> > >
> > > Have you noticed that the wstunnell stuff makes the suspended count
> in
> > > the MPM grow? There is no API for us to tell the MPM that when we
> get
> > > the socket-activity callback that we are "resuming" something.
> > >
> > > (going from vague recollection)
> >
> > It seems that we increment it once when the handler returns SUSPENDED,
> > and decrement it once per connection too in proxy_wstunnel_finish().
> 
> This didn't even ring a bell :)
> 
> But won't we return SUSPENDED many times to a single finish?

Not really, because once we are suspended we only get triggered by timer events
until we leave this state in proxy_wstunnel_finish.

Regards

Rüdiger

AW: async mod_proxy_http

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 13. September 2018 01:59
> An: httpd-dev 
> Betreff: Re: async mod_proxy_http
> 
> On Wed, Sep 12, 2018 at 5:53 PM Eric Covener  wrote:
> >
> > Forking from the Cool Stuff thread.
> >
> > Have you noticed that the wstunnell stuff makes the suspended count in
> > the MPM grow? There is no API for us to tell the MPM that when we get
> > the socket-activity callback that we are "resuming" something.
> >
> > (going from vague recollection)
> 
> It seems that we increment it once when the handler returns SUSPENDED,
> and decrement it once per connection too in proxy_wstunnel_finish().
> 
> However, looks like there is unnecessary churn
> proxy_wstunnel_finish(), including a double close since the MPM will
> also finally close the client connection. How about something like the
> attached?

I don't like the "misuse" of c->aborted here. I for instance log in the access 
log whether connections have been aborted or not and this approach would mean 
that all proxied websocket connections would get marked as aborted. Can't we 
use any other flag to tell the MPM to close the socket and push the pool, e.g. 
a note in c->notes?
Why is the lingering close no longer needed?
Why now doing ap_mpm_resume_suspended after 
ap_finalize_request_protocol(baton->r) and 
ap_process_request_after_handler(baton->r)?
 
Regards

Rüdiger

AW: 2.4.x and 2.6.x ... next steps

[Plüm , Rüdiger , Vodafone Group]

Von: William A Rowe Jr 
Gesendet: Mittwoch, 12. September 2018 03:15
An: httpd 
Betreff: Re: 2.4.x and 2.6.x ... next steps

On Tue, Sep 11, 2018, 17:42 Graham Leggett 
mailto:minf...@sharp.fm>> wrote:
On 11 Sep 2018, at 20:35, Jim Jagielski 
mailto:j...@jagunet.com>> wrote:



We have never dropped code without requiring an actual veto, or the committee 
withdrawing their code.

To my understanding we talk about code that “does not work” and has “issues”. 
So I have never seen a need to veto code in order to fix it. Fixing code can 
also include dropping parts of the code.
I guess you are more worried that we drop the code of complete “features” from 
trunk. As with other stuff I think we just need to discuss on dev@ if there are 
“features” that have issues that need to be fixed.
And if nobody pops up that wants or can fix these issues then dropping it is 
IMHO a valid option as well. If you want to do that via a formal veto on the 
original commit is another topic. I guess this is warranted for big
contributions like whole modules. I think that if we as a group decide in the 
open that a certain feature for a new major release is undesirable for whatever 
reason it is fine to drop it and thus the code even from trunk if nobody is 
willing to work on it and maintain it.
Actually the code will never be dropped. You just need to dig in the svn 
history to find it.
I think the whole point goes more in the direction that the review on trunk is 
sometimes too “sloopy” so that we accumulate unfinished, buggy and untested 
stuff instead of having these issues solved when the code was committed
and the contributor is still available and up to speed for discussion and 
resolution.
One other approach would point in the direction to have major releases more 
often such that these issues are detected earlier.
As proposed on this thread I guess a traversal of the stalled backport 
proposals for 2.4.x is a good starting point to pick up issues in trunk.
I guess we need to pay some price for getting 2.5.x / trunk in a GA releasable 
state in order to publish 2.6.x:


1.   Either we try to stabilize stuff on trunk, but this means we need to 
back down with new fancy ‘unstable’ commits on trunk (social rule not formal 
RTC).

2.   Or we add that 2.5.x branch which is RTC in between trunk and 2.4.x 
branch and thus slow down the backports to 2.4.

If there are enough people that can work on getting 2.5.x / trunk in a GA 
releasable state I think 1. or 2.  will not take long and thus are acceptable.
OTOH if doing that will become an endless story I think both approaches will 
create a lot of friction. Independent on which way we go we should possibly set 
a rough timeline for finishing this work and return to current state if it 
cannot be done this way in the timeline.

Regards

Rüdiger

AW: Buffer in apache

[Plüm , Rüdiger , Vodafone Group]

Von: Christophe JAILLET 
Gesendet: Dienstag, 21. August 2018 21:54
An: Hemant Chaudhary ; dev@httpd.apache.org; 
us...@httpd.apache.org
Betreff: Re: Buffer in apache

Le 21/08/2018 à 13:50, Hemant Chaudhary a écrit :
Hi All,

I want to use buffer of 512B in apache . I am using mod_proxy_http to send 
request to tomcat and have set  ProxyIOBufferSize 512.

But it is sending message to tomcat with size greater than 512B.

How should I control apache in proxy so that it will send message and receive 
with max buffer size of 512B.

Thanks
Hemant


Hi,

for some reasons, mod_proxy_ajp has the folowing code ([1])
This means that value are silently forced between 8k (AJP_MSG_BUFFER_SZ) and 
64k (AJP_MAX_BUFFER_SZ).
I don't know why this is done this way and it looks spurious

However, the code looks in line with apache 2.2 doc ([2]), but not with 2.4. 
([3])
This looks to something that has not been completely updated in the 2.2 -> 2.4 
process.

Sounds like a useless limitation and mod_proxy_ajp should be aligned on the doc.
IMHO, the test with AJP_MSG_BUFFER_SZ should be removed. (and also the one with 
AJP_MAX_BUFFER_SZ BTW)

I cross-post to dev@ list for others feed-back.

I think the code is correct and the documentation is wrong. mod_proxy_ajp has 
the assumption that it can send the whole request including all headers and 
possibly more request metadata in the first “buffer”. This will fail if this 
buffer is too small. Hence the 8k.

Regards

Rüdiger



CJ



[1]: 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/mod_proxy_ajp.c?diff_format=h=markup#l197
[2]: https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyiobuffersize
[3]: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyiobuffersize

AW: Win build success httpd-trunk

[Plüm , Rüdiger , Vodafone Group]

Von: Apache Lounge 
Gesendet: Donnerstag, 26. Juli 2018 13:32
An: dev@httpd.apache.org
Betreff: Win build success httpd-trunk

Build succeeded!

Thanks

Regards

Rüdiger

AW: AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

Can you try again with latest trunk including r1836613? This should make [2] 
obsolete.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Michal Karm 
> Gesendet: Mittwoch, 25. Juli 2018 10:28
> An: dev@httpd.apache.org; Plüm, Rüdiger, Vodafone Group
> 
> Betreff: Re: AW: Current trunk win build error
> 
> On 07/25/2018 08:24 AM, Plüm, Rüdiger, Vodafone Group wrote:
> >
> > r1836603
> >
> >
> >
> > @Windows folks: Can you please try if trunk mod_proxy builds again on
> Windows?
> >
> >
> >
> 
> I've never thought I would be replying to a call to Windows folks, but
> here I go:
> 
> It builds just fine on Windows with my particular CMake based setup [1],
> with
> this h2 patch still needed [2], because [3] is not pushed to trunk.
> The build completes just fine, the Jenkins job fails on seeing errors in
> the
> error_log during smoke test, reported as [ASF BZ 62567].
> 
> 
> From an email from Jenkins:
> 
> > See <https://ci.modcluster.io/job/httpd-trunk-
> windows/label=w2k12r2/21/display/redirect?page=changes>
> >
> > Changes:
> >
> > [ylavic] mod_proxy_http: forward 100-continue.
> >
> > [rpluem] * ap_proxy_balancer_get_best_worker cannot be exported and
> used as an
> >
> > --
> > [...truncated 1.39 MB...]
> > [Wed Jul 25 01:08:10.845360 2018] [core:error] [pid 3772:tid 3652]
> [client ::1:56189] AH00082: an unknown filter was not added:
> >
> POLICY_TYPEPOLICY_LENGTHPOLICY_KEEPALIVEPOLICY_VARYPOLICY_VALIDATIONPOLI
> CY_CONDITIONALPOLICY_NOCACHEPOLICY_MAXAGE
> > [Wed Jul 25 01:08:10.848257 2018] [core:error] [pid 3772:tid 3652]
> [client ::1:56189] AH00082: an unknown filter was not added:
> >
> POLICY_TYPEPOLICY_LENGTHPOLICY_KEEPALIVEPOLICY_VARYPOLICY_VALIDATIONPOLI
> CY_CONDITIONALPOLICY_NOCACHEPOLICY_MAXAGE
> > [Wed Jul 25 01:08:10.851255 2018] [core:error] [pid 3772:tid 3652]
> [client ::1:56189] AH00082: an unknown filter was not added:
> >
> POLICY_TYPEPOLICY_LENGTHPOLICY_KEEPALIVEPOLICY_VARYPOLICY_VALIDATIONPOLI
> CY_CONDITIONALPOLICY_NOCACHEPOLICY_MAXAGE
> > [Wed Jul 25 01:08:10.854078 2018] [core:error] [pid 3772:tid 3652]
> [client ::1:56189] AH00082: an unknown filter was not added:
> >
> POLICY_TYPEPOLICY_LENGTHPOLICY_KEEPALIVEPOLICY_VARYPOLICY_VALIDATIONPOLI
> CY_CONDITIONALPOLICY_NOCACHEPOLICY_MAXAGE
> 
> 
> Cheers
> Karm
> 
> [1]
> https://github.com/modcluster/ci.modcluster.io/blob/master/windows/httpd
> /build.bat
> [2]
> https://raw.githubusercontent.com/modcluster/ci.modcluster.io/master/win
> dows/httpd/httpd-trunk_CMakeLists.txt.patch
> [3]
> https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/CMakeLists.txt?
> r1=1832855=1832854=1832855
> [ASF BZ 62567] https://bz.apache.org/bugzilla/show_bug.cgi?id=62567
> 
> 
> > Regards
> >
> >
> >
> > Rüdiger
> >
> >
> >
> > *Von:*William A Rowe Jr 
> > *Gesendet:* Dienstag, 24. Juli 2018 18:16
> > *An:* httpd 
> > *Betreff:* Re: Current trunk win build error
> >
> >
> >
> > +1, looks great.
> >
> >
> >
> 
> 
> Michal Karm Babacek
> 
> --
> Sent from my Hosaka Ono-Sendai Cyberspace 7
> 

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

r1836603

@Windows folks: Can you please try if trunk mod_proxy builds again on Windows?

Regards

Rüdiger

Von: William A Rowe Jr 
Gesendet: Dienstag, 24. Juli 2018 18:16
An: httpd 
Betreff: Re: Current trunk win build error

+1, looks great.

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

Unfortunately this did not work and caused.

In file included from mod_proxy.h:30:0,
 from proxy_util.c:18:
proxy_util.c: In function 'proxy_util_register_hooks':
/home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:42:36: error: 
unknown type name 'apr_OFN_proxy_balancer_get_best_worker_t'
#define APR_OPTIONAL_FN_TYPE(name) apr_OFN_##name##_t
^
/home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:71:3: note: in 
expansion of macro 'APR_OPTIONAL_FN_TYPE'
   APR_OPTIONAL_FN_TYPE(name) *apu__opt = name; \
   ^
proxy_util.c:4094:5: note: in expansion of macro 'APR_REGISTER_OPTIONAL_FN'
 APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
 ^
proxy_util.c:4094:30: warning: initialization from incompatible pointer type 
[enabled by default]
 APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
  ^
/home/pluem/apache/httpd-trunk/srclib/apr/include/apr_optional.h:71:42: note: 
in definition of macro 'APR_REGISTER_OPTIONAL_FN'
   APR_OPTIONAL_FN_TYPE(name) *apu__opt = name; \
  ^
make[4]: *** [proxy_util.slo] Error 1
make[3]: *** [shared-build-recursive] Error 1
make[2]: *** [shared-build-recursive] Error 1
make[1]: *** [shared-build-recursive] Error 1
make: *** [all-recursive] Error 1

The attached one which is shorter then my original one, but longer than yours 
and does work.



Regards

Rüdiger

Von: William A Rowe Jr 
Gesendet: Montag, 23. Juli 2018 16:54
An: httpd 
Betreff: Re: Current trunk win build error

I think it's simply the attached (couldn't apply the inline text patch).

No need to change the hook name.

On Mon, Jul 23, 2018 at 9:16 AM, Plüm, Rüdiger, Vodafone Group 
mailto:ruediger.pl...@vodafone.com>> wrote:
So something like the below?

Regards

Rüdiger

Index: modules/proxy/balancers/mod_lbmethod_bybusyness.c
===
--- modules/proxy/balancers/mod_lbmethod_bybusyness.c   (revision 1836460)
+++ modules/proxy/balancers/mod_lbmethod_bybusyness.c(working copy)
@@ -22,8 +22,8 @@
 module AP_MODULE_DECLARE_DATA lbmethod_bybusyness_module;
-static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
-*ap_proxy_balancer_get_best_worker_fn = NULL;
+static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
+*proxy_balancer_get_best_worker_fn = NULL;
 static int is_best_bybusyness(proxy_worker *current, proxy_worker *prev_best, 
void *baton)
{
@@ -47,7 +47,7 @@
{
 int total_factor = 0;
 proxy_worker *worker =
-ap_proxy_balancer_get_best_worker_fn(balancer, r, is_best_bybusyness,
+proxy_balancer_get_best_worker_fn(balancer, r, is_best_bybusyness,
   _factor);
 if (worker) {
@@ -96,9 +96,9 @@
 return OK;
 }
-ap_proxy_balancer_get_best_worker_fn =
- APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
-if (!ap_proxy_balancer_get_best_worker_fn) {
+proxy_balancer_get_best_worker_fn =
+ APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_worker);
+if (!proxy_balancer_get_best_worker_fn) {
 ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(10151)
  "mod_proxy must be loaded for mod_lbmethod_bybusyness");
 return !OK;
Index: modules/proxy/balancers/mod_lbmethod_byrequests.c
===
--- modules/proxy/balancers/mod_lbmethod_byrequests.c(revision 1836460)
+++ modules/proxy/balancers/mod_lbmethod_byrequests.c (working copy)
@@ -22,8 +22,8 @@
 module AP_MODULE_DECLARE_DATA lbmethod_byrequests_module;
-static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
-*ap_proxy_balancer_get_best_worker_fn = NULL;
+static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
+*proxy_balancer_get_best_worker_fn = NULL;
 static int is_best_byrequests(proxy_worker *current, proxy_worker *prev_best, 
void *baton)
{
@@ -84,7 +84,7 @@
 request_rec *r)
{
 int total_factor = 0;
-proxy_worker *worker = ap_proxy_balancer_get_best_worker_fn(balancer, r, 
is_best_byrequests, _factor);
+proxy_worker *worker = proxy_balancer_get_best_worker_fn(balancer, r, 
is_best_byrequests, _factor);
 if (worker) {
 worker->s->lbstatus -= total_factor;
@@ -137,9 +137,9 @@
 return OK;
 }
-ap_proxy_balancer_get_best_worker_fn =
- APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
-if (!ap_proxy_balancer_get_best_worker_fn) {
+proxy_balancer_get_best_worker_fn =
+ APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_worker);
+if (!proxy_balancer_get_best_worker_fn) {
 ap_log_error(APLOG_MARK, APLOG_EMER

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

Replied in bugzilla. Question to our fellow Windows builders: Any issues to 
compile 2.4.34 currently in the way described in

https://bz.apache.org/bugzilla/show_bug.cgi?id=62557#c5

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Michal Karm 
> Gesendet: Dienstag, 24. Juli 2018 07:54
> An: dev@httpd.apache.org
> Cc: William A Rowe Jr 
> Betreff: Re: Current trunk win build error
> 
> Seeing "Rüdiger" (Hello!), "proxy_util" and "win" compels me to ask:
> Is this in any way related to [1] too? Should I be playing with this
> patch as well?
> How come you get pass the mod_http2 error with proxy_util.c?
> 
> I hope the thread won't  catch on fire in CMake/.dsp/.sln/.vcxproj
> flames :)
> 
> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=62557#c5
> 
> Karm
> 

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

Looks better than mine, but as we register the function with a different name 
we need to adjust the parameter to the APR_RETRIEVE_OPTIONAL_FN macro in all 
mod_lbmethod modules as I did, correct?

Regards

Rüdiger

Von: William A Rowe Jr 
Gesendet: Montag, 23. Juli 2018 16:54
An: httpd 
Betreff: Re: Current trunk win build error

I think it's simply the attached (couldn't apply the inline text patch).

No need to change the hook name.

On Mon, Jul 23, 2018 at 9:16 AM, Plüm, Rüdiger, Vodafone Group 
mailto:ruediger.pl...@vodafone.com>> wrote:
So something like the below?

Regards

Rüdiger

Index: modules/proxy/balancers/mod_lbmethod_bybusyness.c
===
--- modules/proxy/balancers/mod_lbmethod_bybusyness.c   (revision 1836460)
+++ modules/proxy/balancers/mod_lbmethod_bybusyness.c(working copy)
@@ -22,8 +22,8 @@
 module AP_MODULE_DECLARE_DATA lbmethod_bybusyness_module;
-static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
-*ap_proxy_balancer_get_best_worker_fn = NULL;
+static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
+*proxy_balancer_get_best_worker_fn = NULL;
 static int is_best_bybusyness(proxy_worker *current, proxy_worker *prev_best, 
void *baton)
{
@@ -47,7 +47,7 @@
{
 int total_factor = 0;
 proxy_worker *worker =
-ap_proxy_balancer_get_best_worker_fn(balancer, r, is_best_bybusyness,
+proxy_balancer_get_best_worker_fn(balancer, r, is_best_bybusyness,
   _factor);
 if (worker) {
@@ -96,9 +96,9 @@
 return OK;
 }
-ap_proxy_balancer_get_best_worker_fn =
- APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
-if (!ap_proxy_balancer_get_best_worker_fn) {
+proxy_balancer_get_best_worker_fn =
+ APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_worker);
+if (!proxy_balancer_get_best_worker_fn) {
 ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(10151)
  "mod_proxy must be loaded for mod_lbmethod_bybusyness");
 return !OK;
Index: modules/proxy/balancers/mod_lbmethod_byrequests.c
===
--- modules/proxy/balancers/mod_lbmethod_byrequests.c(revision 1836460)
+++ modules/proxy/balancers/mod_lbmethod_byrequests.c (working copy)
@@ -22,8 +22,8 @@
 module AP_MODULE_DECLARE_DATA lbmethod_byrequests_module;
-static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
-*ap_proxy_balancer_get_best_worker_fn = NULL;
+static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
+*proxy_balancer_get_best_worker_fn = NULL;
 static int is_best_byrequests(proxy_worker *current, proxy_worker *prev_best, 
void *baton)
{
@@ -84,7 +84,7 @@
 request_rec *r)
{
 int total_factor = 0;
-proxy_worker *worker = ap_proxy_balancer_get_best_worker_fn(balancer, r, 
is_best_byrequests, _factor);
+proxy_worker *worker = proxy_balancer_get_best_worker_fn(balancer, r, 
is_best_byrequests, _factor);
 if (worker) {
 worker->s->lbstatus -= total_factor;
@@ -137,9 +137,9 @@
 return OK;
 }
-ap_proxy_balancer_get_best_worker_fn =
- APR_RETRIEVE_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
-if (!ap_proxy_balancer_get_best_worker_fn) {
+proxy_balancer_get_best_worker_fn =
+ APR_RETRIEVE_OPTIONAL_FN(proxy_balancer_get_best_worker);
+if (!proxy_balancer_get_best_worker_fn) {
 ap_log_error(APLOG_MARK, APLOG_EMERG, 0, s, APLOGNO(10152)
  "mod_proxy must be loaded for mod_lbmethod_byrequests");
 return !OK;
Index: modules/proxy/balancers/mod_lbmethod_bytraffic.c
===
--- modules/proxy/balancers/mod_lbmethod_bytraffic.c (revision 
1836460)
+++ modules/proxy/balancers/mod_lbmethod_bytraffic.c  (working copy)
@@ -22,8 +22,8 @@
 module AP_MODULE_DECLARE_DATA lbmethod_bytraffic_module;
-static APR_OPTIONAL_FN_TYPE(ap_proxy_balancer_get_best_worker)
-*ap_proxy_balancer_get_best_worker_fn = NULL;
+static APR_OPTIONAL_FN_TYPE(proxy_balancer_get_best_worker)
+*proxy_balancer_get_best_worker_fn = NULL;
 static int is_best_bytraffic(proxy_worker *current, proxy_worker *prev_best, 
void *baton)
{
@@ -62,7 +62,7 @@
{
 apr_off_t min_traffic = 0;
-return ap_proxy_balancer_get_best_worker_fn(balancer, r, is_best_bytraffic,
+return proxy_balancer_get_best_worker_fn(balancer, r, is_best_bytraffic,
  _traffic);
}
@@ -107,9 +107,9 @@
 return OK;
 }
-ap_proxy_balancer_get_best_worker_fn =
- APR_RETRIEVE_OPTIONAL_FN(a

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

(revision 1836460)
+++ modules/proxy/mod_proxy.h   (working copy)
@@ -883,7 +883,7 @@
/*
  * Needed by the lb modules.
  */
-APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_worker,
+APR_DECLARE_OPTIONAL_FN(proxy_worker *, proxy_balancer_get_best_worker,
 (proxy_balancer *balancer,
  request_rec *r,
  proxy_is_best_callback_fn_t *is_best,
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c (revision 1836460)
+++ modules/proxy/proxy_util.c  (working copy)
@@ -1415,6 +1415,13 @@
 return best_worker;
}
+static proxy_worker* proxy_balancer_get_best_worker(proxy_balancer *balancer,
+request_rec *r,
+
proxy_is_best_callback_fn_t *is_best,
+void *baton)
+{
+return ap_proxy_balancer_get_best_worker(balancer, r, is_best, baton);
+}
/*
  * CONNECTION related...
  */
@@ -4079,5 +4086,5 @@
{
 APR_REGISTER_OPTIONAL_FN(ap_proxy_retry_worker);
 APR_REGISTER_OPTIONAL_FN(ap_proxy_clear_connection);
-APR_REGISTER_OPTIONAL_FN(ap_proxy_balancer_get_best_worker);
+APR_REGISTER_OPTIONAL_FN(proxy_balancer_get_best_worker);
}

Von: William A Rowe Jr 
Gesendet: Montag, 23. Juli 2018 16:04
An: httpd 
Betreff: Re: Current trunk win build error

Perhaps use proxy_balancer_get_best_worker, and don't export
that? That can be the delegate for ap_proxy_balancer_get_best_worker.

We either keep callbacks local, or export them _NONSTD. All the
*_DECLARE (without _NONSTD) are not usable as apr/httpd
callbacks.


On Mon, Jul 23, 2018 at 7:22 AM, Plüm, Rüdiger, Vodafone Group 
mailto:ruediger.pl...@vodafone.com>> wrote:

> -Ursprüngliche Nachricht-
> Von: Apache Lounge mailto:i...@apachelounge.com>>
> Gesendet: Montag, 23. Juli 2018 13:35
> An: dev@httpd.apache.org<mailto:dev@httpd.apache.org>
> Betreff: Current trunk win build error
>
>
>
>
>
> Error C2440 'initializing': cannot convert from 'proxy_worker
> *(__stdcall *)(proxy_balancer *,request_rec
> *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to
> 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)'
>
> mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082
>
Windows experts to the rescue please :-)
Seems to be an issue between PROXY_DECLARE and the optional function stuff.
Does the following patch fix it (just guessing)?

Index: mod_proxy.h
===
--- mod_proxy.h (revision 1836460)
+++ mod_proxy.h (working copy)
@@ -883,7 +883,7 @@
 /*
  * Needed by the lb modules.
  */
-APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_worker,
+APR_DECLARE_OPTIONAL_FN(PROXY_DECLARE(proxy_worker *), 
ap_proxy_balancer_get_best_worker,
 (proxy_balancer *balancer,
  request_rec *r,
  proxy_is_best_callback_fn_t *is_best,



Regards

Rüdiger

AW: Current trunk win build error

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Apache Lounge 
> Gesendet: Montag, 23. Juli 2018 13:35
> An: dev@httpd.apache.org
> Betreff: Current trunk win build error
> 
> 
> 
> 
> 
> Error C2440 'initializing': cannot convert from 'proxy_worker
> *(__stdcall *)(proxy_balancer *,request_rec
> *,proxy_is_best_callback_fn_t (__cdecl *),void *)' to
> 'apr_OFN_ap_proxy_balancer_get_best_worker_t (__cdecl *)'
> 
> mod_proxy c:\vc15\win32\httpd-trunk\modules\proxy\proxy_util.c 4082
> 

Windows experts to the rescue please :-)
Seems to be an issue between PROXY_DECLARE and the optional function stuff.
Does the following patch fix it (just guessing)?

Index: mod_proxy.h
===
--- mod_proxy.h (revision 1836460)
+++ mod_proxy.h (working copy)
@@ -883,7 +883,7 @@
 /*
  * Needed by the lb modules.
  */
-APR_DECLARE_OPTIONAL_FN(proxy_worker *, ap_proxy_balancer_get_best_worker,
+APR_DECLARE_OPTIONAL_FN(PROXY_DECLARE(proxy_worker *), 
ap_proxy_balancer_get_best_worker,
 (proxy_balancer *balancer,
  request_rec *r,
  proxy_is_best_callback_fn_t *is_best,



Regards

Rüdiger

AW: mod_ssl and openssl 1.0.2 initialization

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Montag, 23. Juli 2018 11:50
> An: httpd-dev 
> Betreff: Re: mod_ssl and openssl 1.0.2 initialization
> 
> On Wed, Jul 18, 2018 at 3:14 PM, Stefan Eissing
>  wrote:
> > Something fishy reported in
> > https://bz.apache.org/bugzilla/show_bug.cgi?id=62552
> >
> > Which points to a problem with CRYPTO_THREADID and crypto locks and
> > initialization oder in OpenSSL 1.0.2. (I believe OpenSSL 1.1.x
> > eleminated that).
> >
> > During the analysis of the bug, there seem to be 3 modules in play
> > that use openssl: mod_ssl, mod_md and mod_authn_dbd (mysql).
> > Depending on configuration and load order the server works or
> > crashes.
> 
> Yes, I agree that we have an issue with openssl (< 1.1)
> loading/unloading/initialization for different modules: core, mod_ssl,
> mod_md, mod_crypto (via APR), mod_authn_dbd (I wasn't aware of this
> one using openssl), ... (others?) may all use openssl and in arbitrary
> order depending on the configuration.

You forgot mod_ldap depending on the LDAP library being used and how this
Library was compiled to support SSL.

> 
> 
> > Generally, the rule seems to be:
> >
> > - without mod_authn_dbd (and directive for mysql driver), all is
> > well - with it, crash in mod_md md_crypto_init (which calls
> > RAND_status(), which crashes) - *unless* mod_ssl is loaded before the
> > others.
> >
> > This seems a bit nasty. Does someone of our mod_ssl experts agree to
> > this analysis and that crypto locking is the issue?
> >
> > If so, what can we do about it?
> 
> I started to try to centralize openssl setup in APR (r1833421, but I'm
> being cautious here because it kind of has been reverted lately...).
> What do you think of an 'apr_crypto_lib_init("openssl", ..., pool)'
> call from any module, where all the init/cleanup would be done once
> for all with the lifetime of the given pool (pconf, or pglobal if the
> core itself uses openssl).
> It does not include threads' locking for now, but this could be added
> based on existing httpd code.
> 
> Unfortunately in any case this will require APR-1.7 (at best), so in
> the meantime we might want an httpd only solution, like optional
> functions.
> I wonder which module would provide them though, mod_ssl looks quite
> straightforward but then it would be a requirement for, e.g.
> mod_authn_dbd? This does not look right either...
> Or maybe there could be a way to autoload a mod_openssl (functional
> only) module?

This looks like the most sane way. It could become very thin once something
in APR is available. Do we need to do the same for other crypto libraries, but
openssl or do they have a better design with this respect? If it is needed for 
them
as well, we should have one module that covers them all, not just openssl.

Regards

Rüdiger

AW: ocsp_force_default initialized with UNSET in httpd 2.4.34

[Plüm , Rüdiger , Vodafone Group]

Wrong revision. Correct one is r1836472.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Plüm, Rüdiger, Vodafone Group 
> Gesendet: Montag, 23. Juli 2018 11:26
> An: dev@httpd.apache.org
> Betreff: AW: ocsp_force_default initialized with UNSET in httpd 2.4.34
> 
> This is now backported to 2.4.x as r1555631 and will be part of the next
> release.
> 
> Regards
> 
> Rüdiger
> 
> > -Ursprüngliche Nachricht-
> > Von: Frank Meier 
> > Gesendet: Freitag, 20. Juli 2018 09:26
> > An: dev@httpd.apache.org
> > Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
> >
> >
> > On 18/07/18 13:57, Ruediger Pluem wrote:
> > >
> > > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> > >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic :
> > >>>
> > >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem
> 
> > wrote:
> > >>>> Good catch. Maybe a dirty working copy during backport? Yann?
> > >>> Actually the change was in the proposed patch:
> > >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-
> ocsp-
> > enable-leaf.patch
> > >>> A subtle difference between trunk and 2.4.x, around the change...
> > >> Hmm, so I had the dirty working dir when creating the patch? I do
> not
> > remember messing with that setting, but obviously I was mistaken in
> > doing it.
> > >>
> > >> So, patch 1 it is then, Rainer?
> > >>
> > > I changed my mind :-) Let's backport r1555631 from trunk which is
> more
> > or less patch 2. So we have aligned trunk and
> > > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> > r1827001 are already backported, but this is fixable.
> > >
> > > Regards
> > >
> > > Rüdiger
> > Thanks Guys, so we will run with patch 2. For now.
> > Just for other people to know if they hit this issue with 2.4.34 and
> are
> > not able to patch, there is a workaround: Explicitly setting the
> > directive "SSLOCSPOverrideResponder" to "off" in the configuration
> file
> > does also "fix" the issue.
> >
> > Cheers, Frank

AW: ocsp_force_default initialized with UNSET in httpd 2.4.34

[Plüm , Rüdiger , Vodafone Group]

This is now backported to 2.4.x as r1555631 and will be part of the next 
release.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Frank Meier 
> Gesendet: Freitag, 20. Juli 2018 09:26
> An: dev@httpd.apache.org
> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
> 
> 
> On 18/07/18 13:57, Ruediger Pluem wrote:
> >
> > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic :
> >>>
> >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem 
> wrote:
>  Good catch. Maybe a dirty working copy during backport? Yann?
> >>> Actually the change was in the proposed patch:
> >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-
> enable-leaf.patch
> >>> A subtle difference between trunk and 2.4.x, around the change...
> >> Hmm, so I had the dirty working dir when creating the patch? I do not
> remember messing with that setting, but obviously I was mistaken in
> doing it.
> >>
> >> So, patch 1 it is then, Rainer?
> >>
> > I changed my mind :-) Let's backport r1555631 from trunk which is more
> or less patch 2. So we have aligned trunk and
> > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> r1827001 are already backported, but this is fixable.
> >
> > Regards
> >
> > Rüdiger
> Thanks Guys, so we will run with patch 2. For now.
> Just for other people to know if they hit this issue with 2.4.34 and are
> not able to patch, there is a workaround: Explicitly setting the
> directive "SSLOCSPOverrideResponder" to "off" in the configuration file
> does also "fix" the issue.
> 
> Cheers, Frank

AW: Bug in mod_ratelimit?

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Montag, 23. Juli 2018 10:52
> An: httpd-dev 
> Betreff: Re: Bug in mod_ratelimit?
> 
> On Mon, Jul 23, 2018 at 7:45 AM, Plüm, Rüdiger, Vodafone Group
>  wrote:
> >
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Eric Covener 
> >> Gesendet: Sonntag, 22. Juli 2018 21:58
> >> An: Apache HTTP Server Development List 
> >> Betreff: Re: Bug in mod_ratelimit?
> >>
> >> > > You probably didn't test with chunked encoding (neither did I!),
> see
> >> > > how ap_http_header_filter() adds the "CHUNK" filter after the
> >> headers
> >> > > have been sent, so if anything retains the headers they will be
> >> > > considered as the body by the (late) ap_http_chunk_filter()..
> >>
> >> would it be reasonable to send a flush down, and/or track whether the
> >> headers are flushed somewhere out of the http filter ctx?
> >
> > Flush in case of mod_ratelimit or in general?
> 
> mod_ratelimit FLUSHes data already, and the first patch proposed here
> allowed the headers to pass with a FLUSH.
> Yet if headers are large enough to be rate limited, the first ones
> will pass before the "CHUNK" filter is added, but not the next ones.
> 
> > In general wouldn't
> > that cause "smaller" TCP packets to be sent if content is ready and
> > the headers are "short" and hence cause some performance
> > degradation?
> 
> In the general case I agree that we shouldn't always flush the
> headers, moreover mod_ratelimit isn't supposed to (and doesn't) honor
> FLUSHes. The rate is applied regardless of FLUSH buckets from previous
> filters.
> 
> One way to possibly address this would be to handle a new EOH (End Of
> Header) meta-bucket, à la EOS/EOR/..
> ap_http_header_filter() would add the "CHUNK" filter first and then
> pass the headers brigade ended by EOH.
> The "CHUNK" filter would do nothing until EOH.
> 
> I think my patch "rate_limit_filter+header_only.patch" is needed
> anyway w.r.t. header_only handling in ap_http_header_filter() and EOS.

I think above patches are the best way to get ahead right now.

Regards

Rüdiger

AW: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ modules/proxy/ modules/proxy/balancers/

[Plüm , Rüdiger , Vodafone Group]

Von: William A Rowe Jr  
Gesendet: Freitag, 20. Juli 2018 23:03
An: httpd 
Betreff: Re: svn commit: r1836381 - in /httpd/httpd/trunk: ./ include/ 
modules/proxy/ modules/proxy/balancers/


On Fri, Jul 20, 2018, 15:22 Ruediger Pluem  wrote:

BTW: We have the same load order issue issue with the following proxy modules:

mod_proxy_connect
mod_proxy_ftp
mod_proxy_http
mod_proxy_fcgi
mod_proxy_scgi
mod_proxy_fdpass
mod_proxy_ajp
mod_proxy_balancer
mod_proxy_express

> Correct. However this isn't a regression, and mod_proxy is an apparent 
> prerequisite to any of these,
> which further and thankfully sorts first. The lbmethod providers differed in 
> all three respects.
>

Correct, but we are little bit lucky with the sort ordering here (or was it by 
design from the very beginning?)
 
> It might be interesting to solve in a future enhancement release, but the 
> number of dependencies
> likely makes this unrealistic.

This is what I stumbled across. I found it kind of weird to add an 
APR_DECLARE_OPTIONAL_FN for ap_proxy_balancer_get_best_worker
just after the PROXY_DECLARE for the same in mod_proxy.h. Later I understood 
why: We make the mod_proxy API accessible here
via 2 different ways.
I think mod_proxy is somewhat unique here as it seems to be the only module 
that is not always linked statically (like mod_core)
that provides a high number of functions that are consumed by "sub"-modules.
In case of other non core modules we usually encapsulate that via optional 
functions, provider interfaces or hooks. So probably
also in the light of mod_proxy_http2 a review should be due how we can provide 
this API functionality in a less load
dependent way. But I agree that it will be a huge, time consuming and 
disruptive (probably even unthankful) change.

Regards

Rüdiger

AW: Bug in mod_ratelimit?

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener 
> Gesendet: Sonntag, 22. Juli 2018 21:58
> An: Apache HTTP Server Development List 
> Betreff: Re: Bug in mod_ratelimit?
> 
> > > You probably didn't test with chunked encoding (neither did I!), see
> > > how ap_http_header_filter() adds the "CHUNK" filter after the
> headers
> > > have been sent, so if anything retains the headers they will be
> > > considered as the body by the (late) ap_http_chunk_filter()..
> 
> would it be reasonable to send a flush down, and/or track whether the
> headers are flushed somewhere out of the http filter ctx?

Flush in case of mod_ratelimit or in general? In general wouldn't that
cause "smaller" TCP packets to be sent if content is ready and the headers are 
"short" and hence cause some performance degradation?

Regards

Rüdiger

AW: ocsp_force_default initialized with UNSET in httpd 2.4.34

[Plüm , Rüdiger , Vodafone Group]

I can do tomorrow and make a proposal in STATUS. Looks like we are all aligned 
now how to resolve this.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Donnerstag, 19. Juli 2018 11:10
> An: dev@httpd.apache.org
> Betreff: Re: ocsp_force_default initialized with UNSET in httpd 2.4.34
> 
> You'll take care of it, Rüdiger?
> 
> > Am 18.07.2018 um 13:57 schrieb Ruediger Pluem :
> >
> >
> >
> > On 07/18/2018 11:44 AM, Stefan Eissing wrote:
> >>> Am 18.07.2018 um 11:37 schrieb Yann Ylavic :
> >>>
> >>> On Wed, Jul 18, 2018 at 11:29 AM, Ruediger Pluem 
> wrote:
> 
>  Good catch. Maybe a dirty working copy during backport? Yann?
> >>>
> >>> Actually the change was in the proposed patch:
> >>> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-ocsp-
> enable-leaf.patch
> >>> A subtle difference between trunk and 2.4.x, around the change...
> >>
> >> Hmm, so I had the dirty working dir when creating the patch? I do not
> remember messing with that setting, but obviously I was mistaken in
> doing it.
> >>
> >> So, patch 1 it is then, Rainer?
> >>
> >
> > I changed my mind :-) Let's backport r1555631 from trunk which is more
> or less patch 2. So we have aligned trunk and
> > 2.4.x here. r1555631 does not apply clean though, because r1826995,
> r1827001 are already backported, but this is fixable.
> >
> > Regards
> >
> > Rüdiger

AW: Time for 2.4.34?

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic 
> Gesendet: Donnerstag, 5. Juli 2018 21:34
> An: httpd-dev 
> Betreff: Re: Time for 2.4.34?
> 
> On Thu, Jul 5, 2018 at 9:11 PM, Yann Ylavic 
> wrote:
> > On Thu, Jul 5, 2018 at 5:43 PM, Jim Jagielski  wrote:
> >> Seems to me that we are just about due for a 2.4.34 release...
> >> Anyone opposed? I volunteer to RM.
> >
> > +1, thanks Jim.
> 
> Possibly someone for the last vote on r1588806?
> This simple change can avoid hard to diagnose bugs, with very little
> risk IMO.

Done. r1835177.

Regards

Rüdiger

AW: svn commit: r1682074 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/ssl/ssl_engine_init.c

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Christophe Jaillet 
> Gesendet: Samstag, 30. Juni 2018 14:08
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1682074 - in /httpd/httpd/branches/2.4.x: ./
> STATUS modules/ssl/ssl_engine_init.c
> 
> Le 27/05/2015 à 18:33, wr...@apache.org a écrit :
> > Author: wrowe
> > Date: Wed May 27 16:33:10 2015
> > New Revision: 1682074
> >
> > URL: http://svn.apache.org/r1682074
> > Log:
> > mod_ssl: fix small memory leak in ssl_init_server_certs when ECDH is
> used.
> > SSL_CTX_set_tmp_ecdh increases reference count, so we have to call
> > EC_KEY_free, otherwise eckey will not be freed.
> >
> > Backports: r1666363
> > Author: jkaluza
> > Reviewed by: rjung, ylavic, wrowe
> >
> 
> Hi,
> 
> This backport looks incomplete.
> 
> In the original patch (r1666363) we have:
> @@ -1151,10 +1151,11 @@
>   #if defined(SSL_CTX_set_ecdh_auto)
>   SSL_CTX_set_ecdh_auto(mctx->ssl_ctx, 1);
>   #else
> -SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx,
> -
> EC_KEY_new_by_curve_name(NID_X9_62_prime256v1));
> +eckey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
> +SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey);
> which is not in the backported code. (neither in the .patch file, nor in
> the backport itself)
> 
> Was it intentional or should the missing part be also backported?
> My feeling is that it should be merged.

I agree that this part should be merged as well.

Regards

Rüdiger

AW: Host header checking too strict?

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener 
> Gesendet: Freitag, 22. Juni 2018 23:21
> An: Apache HTTP Server Development List 
> Betreff: Host header checking too strict?
> 
> After CVE-2016-8743 we only accept hostnames that are valid in DNS,
> which notably excludes underscores.  But it seems like 7230 does not
> require HTTP Host: to use a DNS registry, and excluding  '_' should
> have broken IDN (punycode) international domain names.
> 
> Meanwhile I have seen several reports of e.g. departmental servers or
> proxypreservehost=off-like failures with hostnames w/ underscores.
> 
> Should we be more tolerant here, or offer an option?
> 
> [ ] No
> [X] Just underscores, which seems to come up alot?

Regards

Rüdiger

AW: Brigade memory lifetime & leaks

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Joe Orton 
> Gesendet: Dienstag, 5. Juni 2018 14:48
> An: dev@httpd.apache.org; d...@apr.apache.org
> Betreff: Re: Brigade memory lifetime & leaks
> 
> On Tue, Jun 05, 2018 at 12:07:31PM +, Plüm, Rüdiger, Vodafone Group
> wrote:
> > The usual approach in many locations is to store the created bucket
> brigade
> > and reuse it. How about the following (untested):
> 
> Yes, that works too, thanks!  Passes test suite and fixes the leak,
> though I we need to change the _destroy() to be a _cleanup() for safety,
> and add another, as in attached.

Thanks for fleshing it out.

> 
> I think my long standing hatred for this particular function is because
> every single C API ever created in history with a foo_create()
> foo_destroy() pair has memory allocated by the creator and deallocated
> by the destructor.  But this one is special!

Indeed. _destroy is misleading here and should probably go in APR 2 as you
suggest.

> 
> We should remove apr_brigade_destroy() in APR 2, IMO, or switch to
> bucket allocated brigades then.

The question is whether we add them on top to the current ones or as a 
replacement.

Regards

Rüdiger

AW: Brigade memory lifetime & leaks

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Dienstag, 5. Juni 2018 13:27
> An: dev@httpd.apache.org
> Cc: d...@apr.apache.org
> Betreff: Re: Brigade memory lifetime & leaks
> 
> 
> 
> > Am 05.06.2018 um 10:46 schrieb Joe Orton :
> >
> > In 2.4's http_request.c there are two places doing:
> >
> >bb = apr_brigade_create(c->pool, c->bucket_alloc);
> >
> > to handle sending a FLUSH between requests and an EOR bucket which
> both
> > can't be done off r->pool.  Because the brigade structure itself is
> > allocated out of c->pool this means we leak (~64bytes) per request
> > forever or up to request/conn limits.
> 
> Ok, not good. The first seems only to be triggered when request
> data is still pending, but the second one always happens.
> 
> > We can thread a temp pool through to those functions and fix this,
> > though because these core internal functions are in the public API (ha
> > ha) this is the usual compat PITA, and I haven't worked out if that's
> > more complex for the the async requesta processing call chain.
> > As a PoC for non-async MPMs:
> > http://people.apache.org/~jorton/2.4-use-temp-pool.patch
> >
> > Another choice is to allocate the brigade structure using the bucket
> > allocator and actually free it on _destroy().  Anybody around who can
> > remember why we used a pool allocation for that structure from the
> > beginning?
> 
> How about having the apr_bucket_brigade struct on the stack as an
> option?

The usual approach in many locations is to store the created bucket brigade
and reuse it. How about the following (untested):

Index: modules/http/http_request.c
===
--- modules/http/http_request.c (revision 1832516)
+++ modules/http/http_request.c (working copy)
@@ -345,6 +345,16 @@
 return rv;
 }
 
+#define RETRIEVE_BRIGADE_FROM_POOL(bb, key, pool, allocator) do { \
+apr_pool_userdata_get((void **), key, pool); \
+if (bb == NULL) { \
+bb = apr_brigade_create(pool, allocator); \
+apr_pool_userdata_setn((const void *)bb, key, NULL, pool); \
+} \
+else { \
+apr_brigade_cleanup(bb); \
+} \
+} while(0)
 
 AP_DECLARE(void) ap_process_request_after_handler(request_rec *r)
 {
@@ -357,7 +367,8 @@
  * this bucket is destroyed, the request will be logged and
  * its pool will be freed
  */
-bb = apr_brigade_create(c->pool, c->bucket_alloc);
+RETRIEVE_BRIGADE_FROM_POOL(bb, "ap_process_request_after_handler_brigade",
+   c->pool, c->bucket_alloc);
 b = ap_bucket_eor_create(c->bucket_alloc, r);
 APR_BRIGADE_INSERT_HEAD(bb, b);
 
@@ -477,7 +488,8 @@
 ap_process_async_request(r);
 
 if (!c->data_in_input_filters) {
-bb = apr_brigade_create(c->pool, c->bucket_alloc);
+RETRIEVE_BRIGADE_FROM_POOL(bb, "ap_process_request_brigade", 
+   c->pool, c->bucket_alloc);
 b = apr_bucket_flush_create(c->bucket_alloc);
 APR_BRIGADE_INSERT_HEAD(bb, b);
 rv = ap_pass_brigade(c->output_filters, bb);


Regards

Rüdiger

AW: A proposal...

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener 
> Gesendet: Dienstag, 24. April 2018 15:31
> An: Apache HTTP Server Development List 
> Betreff: Re: A proposal...
> 
> On Tue, Apr 24, 2018 at 8:50 AM, Jim Jagielski  wrote:
> > One idea is that we setup, using the existing perl test framework, a
> sort of "catch all" test, where the framework simply runs all scripts
> from a subdir via system() (or whatever), and the reports success or
> failure. Those scripts could be written in anything. This would mean
> that people could add tests w/o knowing any Perl at all. It would
> require, however, some sort of process since those scripts themselves
> would need to be universal enough that all testers can run them.
> >
> > I may give that a whirl... I have some nodejs scripts that test
> websockets and I may see how/if I can "wrap" them within the test
> framework.
> 
> I fear this would lead to M frameworks and N languages which makes it
> harder for maintainers (prereqs, languages, etc) and fragments
> whatever potential there is for improvements to the harness/tools.

My concern as well. I think this will lead to a less usable framework overall.
It might be more usable for some, but overall it is less usable.
I also have my issues understanding the Perl framework, but I think it should 
be one
framework that is platform independent. I would say that leaves us with Perl, 
Python or
something like that as base language.
If we switch the framework we need to consider that with all gaps we have, we 
already have
a large amount of tests in the current framework that need to be ported over 
time.

Regards

Rüdiger

AW: A proposal...

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Rainer Jung 
> Gesendet: Montag, 23. April 2018 16:47
> An: dev@httpd.apache.org
> Betreff: Re: A proposal...
> 
> Am 23.04.2018 um 16:00 schrieb Jim Jagielski:
> > It seems that, IMO, if there was not so much concern about
> "regressions" in releases, this whole revisit-versioning debate would
> not have come up. This implies, to me at least, that the root cause (as
> I've said before) appears to be one related to QA and testing more than
> anything. Unless we address this, then nothing else really matters.
> >
> > We have a test framework. The questions are:
> >
> >   1. Are we using it?
> >   2. Are we using it sufficiently well?
> >   3. If not, what can we do to improve that?
> >   4. Can we supplement/replace it w/ other frameworks?
> >
> > It does seem to me that each time we patch something, there should be
> a test added or extended which covers that bug. We have gotten lax in
> that. Same for features. And the more substantial the change (ie, the
> more core code it touches, or the more it refactors something), the more
> we should envision what tests can be in place which ensure nothing
> breaks.
> >
> > In other words: nothing backported unless it also involves some
> changes to the Perl test framework or some pretty convincing reasons why
> it's not required.
> 
> I agree with the importance of the test framework, but would also like
> to mention that getting additional test feedback from the community
> seems also important. That's why IMHO the RC style of releasing could be
> helpful by attracting more test effort before a release.

I think RC style releasing could help. Another thought that came to my mind that
I haven't worked out how we could implement this is the following:

Do "double releases". Taking the current state we would do:

Release 2.4.34 and 2.4.35 at the same time. 2.4.34 only contains bug fixes / 
security fixes.
2.4.35 additional features / improvements on top of 2.4.34 as we do so far.

The next "double release" would be 2.4.36 / 2.4.37. 2.4.36 only contains bug 
fixes / security fixes
on top of 2.4.35, 2.4.37 additional features / improvements on top of 2.4.36.
So 2.4.36 would contain the additional features / improvements we had in 2.4.35 
as well, but they
have been in the "wild" for some time and the issues should have been 
identified and fixed as part
of 2.4.36.
Users would then have a choice what to take.

Regards

Rüdiger

AW: A proposal...

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing 
> Gesendet: Montag, 23. April 2018 17:08
> An: dev@httpd.apache.org
> Betreff: Re: A proposal...
> 
> Such undocumented and untested behaviour, which nevertheless is
> considered a regression, cannot be avoided, since it cannot be
> anticipated by people currently working on those code parts. This is a
> legacy of the past, it seems, which we can only overcome by breakage and
> resulting, added test cases.
> 
> > In other words: nothing backported unless it also involves some
> changes to the Perl test framework or some pretty convincing reasons why
> it's not required.
> 
> See above, this will not fix the unforeseeable breakage that results
> from use cases unknown and untested.
> 

Agreed. Even if do perfect testing for all new stuff it will take time until we 
see positive results as the past will hurt us here for a while. So we shouldn't 
give up too fast if do not see positive results immediately 

Regards

Rüdiger

AW: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: David Zuelke 
> Gesendet: Montag, 23. April 2018 18:09
> An: dev@httpd.apache.org
> Betreff: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost
> configs)
> 
> On Sat, Apr 21, 2018 at 12:45 PM, Graham Leggett 
> wrote:
> > On 19 Apr 2018, at 5:55 PM, David Zuelke 
> wrote:
> >
> >> I hate to break this to you, and I do not want to discredit the
> >> amazing work all the contributors here are doing, but httpd 2.4 is of
> >> miserable, miserable quality when it comes to breaks and regressions.
> >>
> >> I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was
> >> able to use the following httpd releases only in the last ~2.5 years:
> >>
> >> - 2.4.16
> >> - 2.4.18
> >> - 2.4.20
> >> - 2.4.29
> >> -2.4.33
> >>
> >> Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL,
> whatever.
> >
> > Did you bring these regressions to our attention? Regressions get fix
> very quickly - there was an 18 month period between 2.4.20 and 2.4.29,
> what stopped it being possible to upgrade in that time?
> 
> I double checked. It was actually 2.4.27, not 2.4.29; 15 months, not 18.
> My bad.
> 
> The issue was the PHP-FPM + mod_proxy_fcgi regression introduced in
> 2.4.21; it got reported pretty quickly but took a while to address.
> 
> It finally got fixed in 2.4.26:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60576
> 
> But that fix broke SCRIPT_NAME:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61202
> 
> So 2.4.27 was functional again.
> 
> That means between April 11, 2016, and July 11, 2017, httpd with
> mod_proxy_fcgi and PHP-FPM was broken.
> 
> The original change was made against trunk
> (https://bz.apache.org/bugzilla/show_bug.cgi?id=59618) and then
> backported to 2.4.next.

Which was an unfortunate regression that took long to be fixed correctly,
but as far as I remember it did not involve any new features nor refactoring.
"Just" a bugfix that caused a regression that was hard to fix.

> 
> >
> > (As other people have said, there was no release between 2.4.16 and
> 2.4.18, 2.4.19 was replaced two weeks later, and there were no releases
> for you to have used between v2.4.29 and 2.4.33)
> >
> >> This is not any person's fault. This is the fault of the process. The
> >> process can be repaired: bugfixes only in 2.4.x, do RC cycles for
> >> bugfix releases as well (that alone makes the changelog look a lot
> >> less confusing, which is useful for the project's image, see also the
> >> Nginx marketing/FUD discussion in the other thread), and start
> testing
> >> new features in modules first.
> >
> > Unfortunately this misses a fundamental reality of what the httpd
> project is - we are the foundation under many many other things, and
> when we jump from v2.4.x to v2.6.x, our complete ecosystem above us
> needs to be recompiled.
> 
> Going from 2.4.x to 2.6.0 doesn't mean that 2.4.x would no longer be
> maintained. There could easily be some predictable, defined support
> policy for keeping older versions alive.

Which requires enough manpower to maintain all these branches. Looking at the 
past
15 years we never maintained more than two stable branches at the same time.
This is no argument against 2.6.0 as we currently only maintain 2.4.x, but 
against
having 2.6+n.0 each time we want to add new features and keep maintaining 
2.6+n-x.0
I think experience shows that if we would release 2.6 the activity to backport 
new
features to 2.4 would drop over time.

> 
> The other thing is ABI versus API stability; you could say 2.x.
> versions retain API compatibility, but not ABI compatibility, so while
> modules would have to be rebuilt against newer version series, that
> could in virtually all cases happen without having to touch the
> module's code.

This might work with open source modules, but even here you would lose the 
chance
e.g. on LTS distributions to compile your own Apache with later features being 
on
the same ABI level as the OS delivered Apache and install a OS delivered package
of a module to use it with this instead of needing to compile it on your own.
It does not work at all with closed source modules, because as soon as these
vendors need to recompile you will either have to wait for a longer period of
time or need to upgrade their product as well to a newer version.

> 
> >> It makes such little sense to land h2 support in 2.4.something, as
> >> opposed to having it as an official "brand new, try it out"
> subproject
> >> first, and then bundle it with 2.6.
> >
> > Not only does it make sense, but it is vital we do so.
> >
> > We needed to get h2 support into the hands of end users - end users
> who were not going to recompile their entire web stack, who install
> software from distros who are not going to upgrade, who were deploying
> modules from vendors that were not going to recompile.
> 
> But that's what I'm saying. Why was h2 not kept as a 

AW: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Plüm , Rüdiger , Vodafone Group]

I am also more in the "ship when it is ready", then "ship when it is time" boat.
We probably could have some automated "nightlyies" which are not releases in 
the ASF sense (as release requires voting),
but only some sort of convenience transformation of an svn export / co that 
creates a tar ball.
But this only creates value if a broader audience tests them.
But I guess most people that benefit from this easier processing of 
"nightlyies" would only test them when they see that
something interesting is contained for them.
Which brings us back to "ship when its ready". OTOH " nightlyies" would add 
testers that have different / their own
criteria's on "when it is ready"

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski 
> Gesendet: Donnerstag, 19. April 2018 15:06
> An: dev@httpd.apache.org
> Betreff: Re: So... when should we do 2.4.34? [WAS: Re: Revisit
> Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]
> 
> One of the great things about working on open source is that
> one is NOT burdened by schedules. That releases are done
> "when ready" not when some artificial schedule or some
> calendar date demands. Changing this mindset on httpd would
> be an extremely major change, IMO, from what's been at its
> heart since 1995. Some may say that that is a good thing,
> that we need to "get inline with the times"... I would disagree,
> especially if we still want to encourage new contributions,
> new contributors and new (volunteer) committers.
> 
> I submit that "doing a release" is not one of the problems that should
> be a priority to "fix".
> 
> > On Apr 19, 2018, at 1:24 AM, Stefan Eissing
>  wrote:
> >
> > Daniel,
> >
> > would you find it feasible to make a 2.4 release every first Tuesday
> of the month? Other projects have excellent experiences with such
> release timings.
> >
> > I‘d expect this would let us focus on the changes („one more week
> until release“), take off pressure („we can do it in the next release“),
> avoid meta discussions („is this a good time?“) and let us streamline
> the test/release work with changes in process/automation with a higher
> motivation.
> >
> > Again, this would be your burden and call until we have so much
> routine/automation that everyone can do it. So it needs to be your
> decision.
> >
> > Cheers, Stefan
> >
> >> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
> >>
> >> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>  The release cycle is hours, to the benefit of all interested. Be it
> a blocking bug fixed or a nice feature implemented. These are mostly
> people who do it for fun. Some even run large server clusters, so a
> „hobbyist“ label does not apply.
> >>> Hours, yes, but we've had a willing RM, who has automated even
> >>> more of this than Jim or I had, and has a very hard time finding
> >>> any target to point to. E.g. "ok, that looks like the right
> resolution
> >>> to the last of the regressions... let's..." ... "...oh there are all
> these
> >>> other shiny objects in STATUS... rock-n-roll!!!"
> >>> ...
> >>
> >> What's particularly interesting to me, as I follow the conversation
> in
> >> my usual lurker-mode, is that Bill hit the nail on the head with this
> >> observation. I was waiting for the dust to settle to run through the
> >> scripts again for another T and release vote... but am not totally
> >> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> >> the merging discussion so instead started parsing for "Yep. We're
> good
> >> now.")
> >>
> >> My current read on the conversation is that we're happy (or maybe
> just
> >> content) with the SSL merging fixes and we should prep to ship 2.4.34
> as
> >> a fix. Does anyone disagree?
> >>
> >> --
> >> Daniel Ruggeri
> >>
> >

AW: "Most Popular Web Server?"

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Daniel Ruggeri [mailto:drugg...@primary.net]
> Gesendet: Donnerstag, 19. April 2018 02:22
> An: dev@httpd.apache.org
> Betreff: Re: "Most Popular Web Server?"
> 
> On 4/18/2018 11:46 AM, Jim Jagielski wrote:
> 
> > Personally, I'd like to see the the PMC take a more active and
> > direct role in addressing #1, maybe w/ monthly blog posts
> > coordinated w/ Sally. It would also be cool to reboot Apache Week
> > (I know it was an external, 3rd party effort) in in conjunction
> > w/ the blog posts or instead of it.
> 
> This is interesting. Can you provide some examples for the types of blog
> posts that you think would be good to make? Stealing from other parts of
> the thread (thanks, Luca!), I could see value in providing bite-sized
> tidbits of how requests/responses are run, what this whole "hook" and
> "pool" stuff is all about and anything to demystify the filter chain.
> Those things could also be used to refresh our developer guidelines
> pages.
> I'm not positive that kind of content is what you have in mind since I
> think that would primarily drive the interest of module authors rather
> than the folks who choose which webserver to use.

Just a quick thought that comes to my mind. I know that there are excellent
presentations at ApacheCon's on various of such topics. Would it be possible
to store / link the slides (need probably be contributed by the authors) and / 
or
videos of the sessions on our website?

Regards

Rüdiger

AW: /scheme/i sensitivity? (was: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Mittwoch, 18. April 2018 18:49
> An: httpd 
> Betreff: /scheme/i sensitivity? (was: svn commit: r1829430 -
> /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)
> 
> On Wed, Apr 18, 2018 at 11:36 AM, Jim Riggs  wrote:
> > Fair enough. I'm fine standardizing either way. strn?cmp() is probably
> more "correct". As it stands, though, the check in core is not actually
> checking everything that log.c will handle.
> 
> There are a number of places where we have "scheme:resource"-style
> resources throughout httpd. Especially mod_ssl.
> 
> Do we want to make a group commitment to strn?casecmp() all of
> these cases in any 2.next/3.0 release?

strn?casecmp() on the scheme part? I guess this would make sense.

Regards

Rüdiger

AW: SNI normalization?

[Plüm , Rüdiger , Vodafone Group]

I guess this makes sense to avoid these kind of issues.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Mittwoch, 11. April 2018 11:49
> An: dev@httpd.apache.org
> Betreff: SNI normalization?
> 
> Feedback desired:
> 
> Checking my server logs, I regularly see clients using SNI with port
> identifier,
> as in: test.example.org:443
> 
> I am not sure what client that is, but we do not identify the vhost that
> is
> (probably) intended. Then the request comes in, and there we have magic
> that
> finds the correct r->server. Then we mod_ssl sees that sslconn->server
> != r->server
> and does some compatibility checks. If the base server and vhost have
> incompatible
> settings (e.g. other certs/ciphers etc.), the request fails.
> 
> This seems to be wrong. Do we need the same normalization that we have
> in Host: header
> parsing in SNI?
> 
> -Stefan

AW: [POLL] Final status of 2.2.x branch

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Rich Bowen [mailto:rbo...@rcbowen.com]
> Gesendet: Mittwoch, 7. März 2018 21:11
> An: dev@httpd.apache.org
> Betreff: Re: [POLL] Final status of 2.2.x branch
> 
> 
> On 02/22/2018 01:27 PM, William A Rowe Jr wrote:
> > On Thu, Feb 22, 2018 at 6:53 AM, Luca Toscano 
> wrote:
> >>
> >> does this mean also removing the doc pages? If so I'd be a little bit
> >> concerned, there are still a lot of people using 2.2 and even not-up-
> to-date
> >> documentation is still better than nothing. Maybe we could send an
> email to
> >> users@ to announce this beforehand?
> >
> > We've long published 1.3 and 2.0 docs after the 2.4 launch. There's no
> > reason to drop 2.2 docs from the website entirely at this time. It is
> > a question whether the 2.2 docs are maintained, or simply kept
> > available in final form?
> >
> > Are you seeking to keep httpd/branches/2.2.x/docs/manual/ open for
> > revision? There need to be three project members willing to maintain
> > and review each others changes, or it is now time to simply close the
> > branch to most edits.
> >
> 
> I've been away for a bit, so I probably lack context here.
> 
> We didn't close the 1.3 docs to edit until ... well, they can still be
> edited, although it's been years since anyone has.
> 
> We should keep the 2.2 docs online, for sure. Making them continue to be
> updated is fine - they still have typos and broken links in them that
> need to be fixed.
> 
> The 1.3 and 2.0 docs died due to lack of interest, not due to policy.
> And, at some point (like after the 2.6 release, for example) we'll want
> to go back and add some rel canonical stuff in the headers to point to
> the newest version.
> 
> I'm just saying that I think it's fine to let them die a natural death,
> rather than killing them by policy.

+1

Regards

Rüdiger

AW: [POLL] Final status of 2.2.x branch

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Eric Covener [mailto:cove...@gmail.com]
> Gesendet: Mittwoch, 21. Februar 2018 16:51
> An: Apache HTTP Server Development List 
> Betreff: Re: [POLL] Final status of 2.2.x branch
> 
> > In the absence of three active contributors, I volunteer to clean up
> > the website, www dist site and svn in the coming days (see the current
> > state of 2.0.x resources for examples), based on original consensus.
> 
> +1

+1

Regards

Rüdiger

AW: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Joe Orton [mailto:jor...@redhat.com]
> Gesendet: Dienstag, 20. Februar 2018 09:20
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS
> 
> On Mon, Feb 19, 2018 at 08:38:05PM +0100, Ruediger Pluem wrote:
> > On 02/19/2018 07:50 PM, Joe Orton wrote:
> > > On Sat, Feb 17, 2018 at 02:06:20PM -, minf...@apache.org wrote:
> > >> Author: minfrin
> > >> Date: Sat Feb 17 14:06:20 2018
> > >> New Revision: 1824592
> > >>
> > >> URL: http://svn.apache.org/viewvc?rev=1824592=rev
> > >> Log:
> > >> Update proposal with fix for rpluem/jorton.
> > >
> > > Extending dav_resource still breaks binary backards compat with
> all(?)
> > > consumers of this API, or am I missing something here?
> >
> > I don't think so. Modules that just work with pointers to structs
> created by mod_dav shouldn't
> > have any issues, but see below.
> 
> Looking again, I think the way the mod_dav API is designed does make it
> necessary for consumers of the API to allocate dav_resource structures.
> There are a number of hooks like ->get_resource():
> 
> dav_error * (*get_resource)(
> request_rec *r,
> const char *root_dir,
> const char *label,
> int use_checked_in,
> dav_resource **resource
> );
> 
> ... which are implemented in repos providers which must allocate that
> *resource, and hence changing sizeof(dav_resource) will break binary BC,
> even if the structure was not embedded anywhere.
> 
> > > Look at what mod_dav_svn does with the struct for an example:
> > >
> https://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/re
> pos.c?view=markup#l80
> >
> > I guess this gets us back to this _copy / _sizeof discussion we had in
> another thread recently.
> > Creating structures / allocating memory for them in modules is IMHO a
> recipe to fail with our current
> > backporting policy as we allow to extend structures at the end.
> 
> Yup.
>
> In this case would moving ->acls and ->ctx to a pool note of the ->pool 
> field (actually is ->ctx actually used??) might work to preserve BC?

Having reviewed the above more closely and letting it sink in I just voted -1
for this backport proposal (r1824928).
I think it would not be fair to let the consumers of the mod_dav API pay the 
price
for a conflict between its API design and our backporting rules that we have 
created.
Let's fix this up in trunk for the next major release (either in the mod_dav 
API directly
or by providing appropriate helpers for creating / allocating / copying such 
structs as
discussed in the other thread.)
Note that this is no general -1 on the ACL extension, but on the way we add it 
to the
existing API in 2.4.x (no -1 on the respective trunk revision). If we find 
another way
to bring it in (e.g. as outlined above) I am fine. But we should probably let 
people
know upfront that this API interface is subject to change in the next major 
release.

Regards

Rüdiger

AW: Binary Breakage (was: svn commit: r1824592 - /httpd/httpd/branches/2.4.x/STATUS)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 20. Februar 2018 22:29
> An: httpd 
> Betreff: Re: Binary Breakage (was: svn commit: r1824592 -
> /httpd/httpd/branches/2.4.x/STATUS)
> 
> On Tue, Feb 20, 2018 at 2:57 PM, Ruediger Pluem 
> wrote:
> >
> > On 02/20/2018 09:39 PM, William A Rowe Jr wrote:
> >
> >> Moving a member in a well-defined structure doesn't fall into this
> >> generally accepted change (expanding the length of a struct.)
> >> Consider the shm array change doesn't fall into the "it is just
> >> a longer struct" example.
> >
> > Can you please give me a pointer which shm array change you are
> referring to?
> 
> r1824504

Thanks.

What particular breakage are you referring to in the above revision?
As far as I can tell, the bug does not get fixed for modules that do not use 
the new field, but it doesn't break them.

Regards

Rüdiger

AW: New ServerUID directive

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:j...@jagunet.com]
> Gesendet: Freitag, 2. Februar 2018 15:15
> An: httpd 
> Betreff: Re: New ServerUID directive
> 
> Why? If it is designed to not change between restarts then
> there are much easier ways to be unique, which it kinda
> already is, considering the actual structs being used.
> 
> Also, this seems like unnecessary admin overhead for the
> webmaster... if there is a need for such an ID, httpd should
> provide for it automagically and not require users to have
> to config one. It seems like config-file fluff to me, IMO.

+1. If the current ID used is not meeting our requirements, my first thought 
would be if we could improve it
to meet them.

Regards

Rüdiger

AW: svn commit: r1822878 - in /httpd/httpd/trunk/modules: http2/h2_config.c http2/h2_config.h http2/h2_conn.c http2/mod_http2.c http2/mod_http2.h proxy/config.m4 proxy/proxy_util.c

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Donnerstag, 1. Februar 2018 16:15
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1822878 - in /httpd/httpd/trunk/modules:
> http2/h2_config.c http2/h2_config.h http2/h2_conn.c http2/mod_http2.c
> http2/mod_http2.h proxy/config.m4 proxy/proxy_util.c
> 
> 
> 
> > Am 01.02.2018 um 16:11 schrieb Yann Ylavic :
> >
> > On Thu, Feb 1, 2018 at 3:58 PM, ste...@eissing.org
>  wrote:
> >> Hmm...
> >>
> >>> Am 01.02.2018 um 15:42 schrieb yla...@apache.org:
> >>>
> >>> +/*
> >>> + * When mod_http2 is loaded we might have more processing
> threads
> >>> + * since it has it's own pool of processing threads.
> >>> + */
> >>> +ap_mpm_query(AP_MPMQ_MAX_THREADS, _threads);
> >>> +if (have_get_h2_num_workers) {
> >>> +get_h2_num_workers(s, , );
> >>> +if (max_threads < maxw) {
> >>> +max_threads = maxw;
> >>> +}
> >>> +}
> >>
> >> Is this what you want? I think the max number of threads
> >> that a proxy worker may be active in is:
> >>
> >>   (max_threads-1) + maxw
> >
> > The max number of connections a proxy worker might have to handle
> > simultaneously is the maximum number of threads requesting one at the
> > same time.
> >
> > The default for minw (ThreadsPerChild) and the doc about H2MaxWorkers
> > saying "This directive sets the maximum number of worker threads to
> > spawn per child process for HTTP/2 processing" suggested (to me) that
> > H2MaxWorkers already included ThreadsPerChild.
> > But if it should be "(max_threads-1) + maxw" per above, well, I trust
> you ;)
> >
> >>
> >> with a single HTTP/2 connection, running maxw streams in
> >> parallel over proxy?
> >
> > Can't each stream by proxied?
> 
> Maybe I am confused, but I see the max at
> 
> n-1 HTTP/1.1 connections with requests of the same proxy
> 1   HTTP/2 connection,
> with m streams in parallel over the same proxy
> 
> With current implementation, the limits are:
> n <= ThreadsPerChild
> m <= maxw
> 
> or?

This is my understanding as well. So something like:

Index: proxy_util.c
===
--- proxy_util.c(revision 1822880)
+++ proxy_util.c(working copy)
@@ -1850,9 +1850,7 @@
 get_h2_num_workers = APR_RETRIEVE_OPTIONAL_FN(http2_get_num_workers);
 if (get_h2_num_workers) {
 get_h2_num_workers(s, , );
-if (max_threads < maxw) {
-max_threads = maxw;
-}
+max_threads = max_threads - 1 + maxw;
 }
 if (max_threads > 1) {
 /* Default hmax is max_threads to scale with the load and never

Regards

Rüdiger

AW: svn commit: r1822849 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 1. Februar 2018 09:49
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: svn commit: r1822849 -
> /httpd/httpd/trunk/modules/proxy/proxy_util.c
> 
> On Thu, Feb 1, 2018 at 9:36 AM, Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com> wrote:
> > Thanks for the review. Does r1822858 address your concern?
> 
> I have a different one :p
> 
> Couldn't we have a helper (optional fn) from mod_http2 which give the
> overhead to mod_proxy?
> I quite like the default hmax=0 to just work...

This would be 2nd edition :-)
At least the admin now has a chance to adjust manually. But totally agree
that it would be cool to set the "good" value automatically by default.

Regards

Rüdiger

AW: svn commit: r1822849 - /httpd/httpd/trunk/modules/proxy/proxy_util.c

[Plüm , Rüdiger , Vodafone Group]

Thanks for the review. Does r1822858 address your concern?

Regards

Rüdiger

Von: Greg Stein [mailto:gst...@gmail.com]
Gesendet: Donnerstag, 1. Februar 2018 09:01
An: dev@httpd.apache.org
Betreff: Re: svn commit: r1822849 - 
/httpd/httpd/trunk/modules/proxy/proxy_util.c



On Thu, Feb 1, 2018 at 1:34 AM, > 
wrote:
Author: rpluem
Date: Thu Feb  1 07:34:02 2018
New Revision: 1822849

URL: http://svn.apache.org/viewvc?rev=1822849=rev
Log:
* When mod_http2 is loaded more then ThreadsPerChild backend connections can
  be useful as mod_http2 has an additional thread pool on top of
  ThreadsPerChild.
  But leave the default with ThreadsPerChild.

Modified:
httpd/httpd/trunk/modules/proxy/proxy_util.c

Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1822849=1822848=1822849=diff
==
--- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
+++ httpd/httpd/trunk/modules/proxy/proxy_util.c Thu Feb  1 07:34:02 2018
@@ -1841,8 +1841,7 @@ PROXY_DECLARE(apr_status_t) ap_proxy_ini

 ap_mpm_query(AP_MPMQ_MAX_THREADS, _threads);
 if (mpm_threads > 1) {
-/* Set hard max to no more then mpm_threads */
-if (worker->s->hmax == 0 || worker->s->hmax > mpm_threads) {
+if (worker->s->hmax == 0) {
 worker->s->hmax = mpm_threads;

Would be nice to leave *some* kind of explanatory comment in there. Without 
that comment, the only explanation is "way over there" in commit log messages.

Cheers,
-g

AW: Pruning working branches (Was: Re: Why?)

[Plüm , Rüdiger , Vodafone Group]

+1

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 26. Oktober 2017 10:31
> An: httpd-dev 
> Betreff: Re: Pruning working branches (Was: Re: Why?)
> 
> I like this "attic" idea better, resurrecting something is easier if
> you can find that it ever existed (w/o diving into svn history, à la
> "svn delete").
> 
> On Thu, Oct 26, 2017 at 10:17 AM, Stefan Eissing
>  wrote:
> > Thanks Greg. The proposed change is purely aestetic. You could make a
> > dir /branches/attic" and move all candidates there. People wanting to
> > "resurrect" them can simply move them back. This is not RCS.
> >
> >> Am 25.10.2017 um 20:21 schrieb Greg Stein :
> >>
> >> To be clear: "delete" simply means "no longer seen in HEAD". This is
> version control. The data cannot truly be deleted, so it can always be
> revived. Or reviewed.
> >>
> >> On Oct 25, 2017 12:31, "Marion & Christophe JAILLET"
>  wrote:
> >> Just to mention that before giving a +1, I made a copy of these
> repositories in order to dig later on, in order to see if something
> useful seems to be there.
> >> Don't have that much time these days to play with httpd, but will do
> and will report anything that looks valuable.
> >>
> >> CJ
> >>
> >>
> >> Le 25/10/2017 à 14:29, Jim Jagielski a écrit :
> >> Are there anything of "value" in any of those branches?
> >>
> >> If not, prune away!
> >>
> >> On Oct 24, 2017, at 9:11 AM, William A Rowe Jr 
> wrote:
> >>
> >> On Tue, Oct 24, 2017 at 3:28 AM, Steffen 
> wrote:
> >> On Tuesday 24/10/2017 at 10:26, Steffen wrote:
> >>
> >> Can someone clean up the not needed anymore  backports/branches
> >> http://svn.apache.org/viewvc/httpd/httpd/branches/
> >>
> >> httpd 2.4.1 was tagged at r1243503.
> >>
> >> I'd propose we start by pruning all working branches not updated
> since this tag.
> >>
> >> Thoughts?
> >>
> >>
> >

AW: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 24. Oktober 2017 19:00
> An: httpd 
> Betreff: [Proposal] 2.5.x -> 2.6.0/3.0.0 transition guidelines
> 
> I'd like to propose the following, so we can decide on what course to
> chart between here and there.
> 
> Today we are at 2.5.0-dev, slated to become 2.5.0 non-GA release.
> Through a series of non-GA releases, 2.5.x is eventually approved to
> become the next 'evens' GA release. What we number that by default is
> 2.6.0, or if the group decides the changes are significant enough,
> 3.0.0.
> 
> What I propose now is that we designate all 2.5.x releases as -alpha
> *until the list decides the API (not ABI) changes are complete*.
> That's the only process change.
> 
> We track this through STATUS, with a vote to promote API-changing
> proposals to SHOWSTOPPERs to -beta. So developers will be aware when
> we declare -beta that we will no longer change the API for them, and
> their modules must conform to the new API, barring any radical
> discoveries that prevent us from shipping that API (which might then
> return us to the -alpha phase.)
> 
> E.g. we had a security@ discussion about changing the handling of URI
> significantly so that the meaning of escaped vs. unescaped characters
> is never obtuse. There are several proposals on that table (embargoed
> at that time waiting for our HTTP protocol correctness patches to be
> published.) Those need to come here to dev@. One of them will land in
> STATUS, and will inevitably be upvoted to SHOWSTOPPER status;
> 2.5.x-beta shouldn't happen, IMO, until some code and structure
> changes to accomplish this has been accepted.
> 
> Because it is CTR, we don't need STATUS for patch voting, but I do
> think we want STATUS to identify what is the minimum changes needed to
> declare the next API/ABI-breaking release complete and ready for
> -beta.
> 
> Thoughts?

The guidelines are fine with me and seem to make sense to get to an API
stable next GA. It is good to have a list of 'To Do's' that needs to be done
before next GA. That helps people looking for interesting and useful work to 
spend their time :-).
Once it is decided that the API is stable I guess we need
to branch in order to avoid restraining further progress on trunk by developers
that want to change the API further in an incompatible way. This could still be 
a '2.5.x' branch
that morphs into a 2.6.x or 3.0.x branch later.

My personal itch and use of my regrettably very limited amount of time these 
days is
on the current 2.4 and getting at least some of the features back into it
(a little bit like Jim's approach). This has to do with my dayjob where it is 
much easier
to upgrade to 2.4.next than to a new GA version.
But I see merit in getting more track on moving forward with current trunk to 
something
releasable. So go for the alpha tags and see if you get sufficient votes for it 
and what
the feedback of the broader community is. If it is valuable: Great. If not
or if it doesn't lift off no harm is done IMHO. Then the alpha release will 
just stop
due to lack of interest in the community.


Regards

Rüdiger

AW: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c

[Plüm , Rüdiger , Vodafone Group]

Same here: I don't see why the lbmethods rely on it between 1 and 100 and why 
they cannot work with 100 till 1
Effectively we kill values like 2.5 and the new comment

> it is a number between 1 and 100 (or 0.01 and 1.0).

is wrong since 0.01 is not an allowed value (it will fail the check below).

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:j...@jagunet.com]
> Gesendet: Dienstag, 24. Oktober 2017 15:29
> An: dev@httpd.apache.org
> Cc: c...@httpd.apache.org
> Betreff: Re: svn commit: r1813167 - in /httpd/httpd/trunk: CHANGES
> modules/proxy/mod_proxy.c modules/proxy/mod_proxy_balancer.c
> 
> I don't understand this patch. It looks like we are no lingering
> externally
> representing ldfactor as a float (e.g.: 2.50). Is that right? If so,
> I'm not sure why...
> 
> > On Oct 24, 2017, at 6:50 AM, yla...@apache.org wrote:
> >
> > Author: ylavic
> > Date: Tue Oct 24 10:50:34 2017
> > New Revision: 1813167
> >
> > URL: http://svn.apache.org/viewvc?rev=1813167=rev
> > Log:
> > mod_proxy_balancer: fix runtime lbfactor value changed in 2.4.28.
> >
> > It is assumed to be between 1 and 100 by lbmethods, so normalize it
> > accordingly.
> >
> >
> > Modified:
> >httpd/httpd/trunk/CHANGES
> >httpd/httpd/trunk/modules/proxy/mod_proxy.c
> >httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
> >
> > Modified: httpd/httpd/trunk/CHANGES
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?rev=1813167=18
> 13166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/CHANGES [utf-8] (original)
> > +++ httpd/httpd/trunk/CHANGES [utf-8] Tue Oct 24 10:50:34 2017
> > @@ -1,6 +1,10 @@
> >  -*- coding:
> utf-8 -*-
> > Changes with Apache 2.5.0
> >
> > +  *) mod_proxy_balancer: fix runtime lbfactor value changed in
> 2.4.28. It is
> > + assumed to be between 1 and 100 by lbmethods, so normalize it
> accordingly.
> > + [Yann Ylavic]
> > +
> >   *) mod_md: v1.0.1, ServerName/Alias names from pure-http: virtual
> hosts are no longer
> >  auto-added to a Managed Domain. Error counts of jobs are
> presisted. When the server
> >  restarts (gracefully) any errored staging areas are purged to
> reset the signup/renewal
> >
> > Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c
> ?rev=1813167=1813166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Tue Oct 24 10:50:34
> 2017
> > @@ -104,13 +104,13 @@ static const char *set_worker_param(apr_
> >
> > if (!strcasecmp(key, "loadfactor")) {
> > /* Normalized load factor. Used with BalancerMember,
> > - * it is a number between 1 and 100.
> > + * it is a number between 1 and 100 (or 0.01 and 1.0).
> >  */
> > double fval = atof(val);
> > ival = fval * 100.0;
> > if (ival < 100 || ival > 1)
> > return "LoadFactor must be a number between 1..100";
> > -worker->s->lbfactor = ival;
> > +worker->s->lbfactor = ival / 100;
> > }
> > else if (!strcasecmp(key, "retry")) {
> > /* If set it will give the retry timeout for the worker
> > @@ -2883,7 +2883,7 @@ static int proxy_status_hook(request_rec
> > ap_rvputs(r, ap_proxy_parse_wstatus(r->pool, *worker),
> NULL);
> > ap_rvputs(r, "", (*worker)->s->route, NULL);
> > ap_rvputs(r, "", (*worker)->s->redirect,
> NULL);
> > -ap_rprintf(r, "%.2f",
> (float)((*worker)->s->lbfactor)/100.0);
> > +ap_rprintf(r, "%d", (*worker)->s-
> >lbfactor);
> > ap_rprintf(r, "%d", (*worker)->s->lbset);
> > ap_rprintf(r, "%" APR_SIZE_T_FMT "",
> >(*worker)->s->elected);
> >
> > Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c
> > URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_b
> alancer.c?rev=1813167=1813166=1813167=diff
> >
> 
> ==
> > --- httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c (original)
> > +++ httpd/httpd/trunk/modules/proxy/mod_proxy_balancer.c Tue Oct 24
> 10:50:34 2017
> > @@ -1093,11 +1093,10 @@ static int balancer_handler(request_rec
> > ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(01192)
> "settings worker params");
> >
> > if ((val = apr_table_get(params, "w_lf"))) {
> > -int ival;
> > double fval = atof(val);
> > -ival = fval * 100.0;
> > +int ival = fval * 100.0;
> > if (ival >= 100 && ival <= 1) {
> > -wsel->s->lbfactor = ival;

AW: Pruning working branches (Was: Re: Why?)

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Dienstag, 24. Oktober 2017 15:12
> An: httpd 
> Betreff: Pruning working branches (Was: Re: Why?)
> 
> On Tue, Oct 24, 2017 at 3:28 AM, Steffen  wrote:
> >
> > On Tuesday 24/10/2017 at 10:26, Steffen wrote:
> >
> > Can someone clean up the not needed anymore  backports/branches
> >  http://svn.apache.org/viewvc/httpd/httpd/branches/
> >
> 
> httpd 2.4.1 was tagged at r1243503.
> 
> I'd propose we start by pruning all working branches not updated since
> this tag.
> 
> Thoughts?

+1

Regards

Rüdiger

AW: Simplify download distribution directory by dropping sha1 hashes?

[Plüm , Rüdiger , Vodafone Group]

Sounds reasonable to me.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
> Gesendet: Montag, 23. Oktober 2017 20:37
> An: httpd 
> Betreff: Simplify download distribution directory by dropping sha1
> hashes?
> 
> HTTPD team,
> 
> Since our downloads are to be authenticated by their .asc PGP
> signatures, and the hashes simply serve as checksums, is it reasonable
> to offer only MD5 and SHA256 at this point?
> 
> Anyone without SHA256 (rare, I'd expect) can use MD5 as the simplest
> supported checksum. All others should apply the strongest hash
> validation.
> 
> Thoughts?
> 
> Bill

AW: mod_rewrite, vary headers and internal redirects

[Plüm , Rüdiger , Vodafone Group]

I would tend to say that the  code is correct and the RewriteCond code is 
wrong, because it doesn’t matter if the condition becomes true or false. The 
headers value has an influence on the result. Tricky question is what to do 
regarding Vary if the non-presence of a header has an influence.

Regards

Rüdiger

Von: Luca Toscano [mailto:toscano.l...@gmail.com]
Gesendet: Sonntag, 22. Oktober 2017 11:47
An: Apache HTTP Server Development List 
Betreff: Re: mod_rewrite, vary headers and internal redirects

Hi everybody,

2017-10-09 13:46 GMT+02:00 Luca Toscano 
>:
Hi Yann,

2017-10-08 14:13 GMT+02:00 Yann Ylavic 
>:
On Sun, Oct 8, 2017 at 2:03 PM, Yann Ylavic 
> wrote:
> Hi Luca,
>
> On Sun, Oct 8, 2017 at 11:59 AM, Luca Toscano 
> > wrote:
>>
>> Does this approach make sense? Is there any smarter way to do it?
>
> I can't tell that I love the hack in internal redirects but looks like
> a simple way to handle the case...
> Nit: maybe a more descriptive name for the "keep-vary-header" note,
> "redirect-keeps-vary"?

+1


But after all, if we reach an internal redirect with some Vary header
already set, maybe we should never drop it, thus internal redirects
should preserve Vary in any case...

I'd prefer to limit the scope of the httpd configurations affected by this 
change to the minimum, but the change would probably look less hacky :)


After https://svn.apache.org/r1811744 trunk should be inline with what the docs 
say, but I have another question now: a RewriteCond condition (containing 
something like HTTP:someheader) adds a Vary header to the response only if the 
condition evaluates to true, meanwhile a  condition adds the Vary header 
regardless. Is there any good motivation for this difference or they should be 
modified to be more consistent? The  block behavior seems to be more sound 
(after reading https://tools.ietf.org/html/rfc7231#section-7.1.4), but I'd like 
to hear more expert opinions :)

Thanks!

Luca

AW: svn commit: r1812393 - in /httpd/httpd/branches/2.4.x: ./ STATUS modules/http2/ modules/http2/config2.m4

[Plüm , Rüdiger , Vodafone Group]

Good point. The original desire was to have lib64 as fallback in order to keep 
the default as is with lib. But probably the reverse order (64 over 32) makes 
more sense these days.
Keen to hear what others say.

Regards

Rüdiger

Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Gesendet: Dienstag, 17. Oktober 2017 17:19
An: httpd 
Cc: c...@httpd.apache.org
Betreff: Re: svn commit: r1812393 - in /httpd/httpd/branches/2.4.x: ./ STATUS 
modules/http2/ modules/http2/config2.m4

IIUC, where this is installed under /usr, we prefer the installed 32 bit libs 
over 64 bit libs where both .i686 and .x86_64 development lib packages are 
provisioned.

Is this the desired priority?

AW: backport patches

[Plüm , Rüdiger , Vodafone Group]

+1

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 12. Oktober 2017 13:24
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: backport patches
> 
> On Thu, Oct 12, 2017 at 1:18 PM, Plüm, Rüdiger, Vodafone Group
> > <ruediger.pl...@vodafone.com> wrote:
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> >> Gesendet: Donnerstag, 12. Oktober 2017 13:12
> >> An: httpd-dev <dev@httpd.apache.org>
> >> Betreff: Re: backport patches
> >>
> >> I like the idea, but since tags are copied from .x branches, they
> will
> >> also include the patches not yet in (heance not really related to the
> >> tag).
> >> A separate branches/2.4.x-patches wouldn't have this issue...
> >
> > Why below branches? Why not in parallel to trunk/ and branches/?
> 
> ^/httpd/httpd/patches/{trunk,2.4.x,...} works for me too.
> 
> Regards,
> Yann.

AW: backport patches

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 12. Oktober 2017 13:12
> An: httpd-dev 
> Betreff: Re: backport patches
> 
> > FYI: I just checked in a "patches" directory inside the 2.4.x branch.
> > I hope it's not picked up in a source distribution.
> 
> Maybe we could have branches/2.4.x-patches instead?
> 
> >
> > If we keep patches for backports/hot-fixes here - instead of all
> > over the world in not-secure http: locations - it should give us
> > tracking and easier use, I hope. I am not fixed on names or structure
> > here, just trying to keep patches where they belong and version
> > them.
> 
> I like the idea, but since tags are copied from .x branches, they will
> also include the patches not yet in (heance not really related to the
> tag).
> A separate branches/2.4.x-patches wouldn't have this issue...

Why below branches? Why not in parallel to trunk/ and branches/?
But in general I agree with your point that patches below branches/2.4.x/ is 
not the best idea for the reasons you state.

Regards

Rüdiger

AW: svn commit: r1811192 - /httpd/httpd/trunk/.gdbinit

[Plüm , Rüdiger , Vodafone Group]

Does r1811570 fix your issue?

Regards

Rüdiger

Von: Luca Toscano [mailto:toscano.l...@gmail.com]
Gesendet: Montag, 9. Oktober 2017 15:34
An: Apache HTTP Server Development List 
Betreff: Re: svn commit: r1811192 - /httpd/httpd/trunk/.gdbinit

Hi Ruediger,

2017-10-05 14:01 GMT+02:00 >:
Author: rpluem
Date: Thu Oct  5 12:01:25 2017
New Revision: 1811192

URL: http://svn.apache.org/viewvc?rev=1811192=rev
Log:
* Add dump_all_pools and dump_pool_and_childs.

  - dump_all_pools: Dump the whole pool hierarchy starting from apr_global_pool.
Requires an arbitrary pool as starting parameter.
  - dump_pool_and_childs: Dump the whole pool hierarchy starting from
  the given pool.

  dump_pool_and_childs is written in Python using the GDB Python API
  as doing recursive stuff in standard GDB macros is very difficult.

Modified:
httpd/httpd/trunk/.gdbinit

Modified: httpd/httpd/trunk/.gdbinit
URL: 
http://svn.apache.org/viewvc/httpd/httpd/trunk/.gdbinit?rev=1811192=1811191=1811192=diff
==
--- httpd/httpd/trunk/.gdbinit (original)
+++ httpd/httpd/trunk/.gdbinit Thu Oct  5 12:01:25 2017
@@ -413,6 +413,98 @@ define dump_one_pool
 printf "' [%p]: %d/%d free (%d blocks)\n", $p, $free, $size, $nodes
 end

+define dump_all_pools
[..]
+print "Pool '%s' [%s]: %d/%d free (%d blocks) allocator: %s free blocks in 
allocator: %i kiB" % (tag, arg, free, size, nodes, darg['allocator'], 
self._allocator_free_blocks(darg['allocator']))

Not sure if I am the only one that has gdb linked with python3.x but this is 
what I get now:

  File "", line 47
print "Pool '%s' [%s]: %d/%d free (%d blocks) allocator: %s free blocks in 
allocator: %i kiB" % (tag, arg, free, size, nodes, darg['allocator'], 
self._allocator_free_blocks(darg['allocator']))
SyntaxError: invalid syntax

Would it be worth to use something like "from future import __print_function__" 
and add () to all the prints?

Thanks!

Luca

AW: httpd memory consumption

[Plüm , Rüdiger , Vodafone Group]

Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Gesendet: Samstag, 7. Oktober 2017 15:52
An: httpd 
Betreff: Re: httpd memory consumption

Have you tried bisecting the config directives to see which is triggering the 
memory abuse?

Sounds like the module might not be async-ready, but should httpd really be 
doing many thread swaps before the listener thread is tripped?

Does one of your modules load a large table al la Geo IP mapping?

Not that I am aware of.

Are you instantiating a scripting runtime, eg PHP or mod_perl?

Nothing like that.

Regards

Rüdiger


On Oct 6, 2017 08:04, "Ruediger Pluem" 
> wrote:


On 10/06/2017 10:26 AM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Ruediger Pluem [mailto:rpl...@apache.org]
>> Sent: vrijdag 6 oktober 2017 09:47
>> To: Apache HTTP Server Development List 
>> >
>> Subject: httpd memory consumption
>>
>> I am currently looking at a core of a httpd 2.4 process using the event MPM
>> that consumed a lot of memory (core dump file size about 1.4 GB).
>> While taking the core actually no request was processed by this process.
>> I suspect a memory leak in a 3rd party closed source module.
>> As I have no view in the 3rd party module I tried to find out the heap
>> memory usage of httpd and the included modules.
>>
>> For this I used the new dump_pool_and_children I added to .gdbinit which
>> delivers me the memory used by all pools below 'apr_global_pool' and the
>> amount of memory in the allocator free lists associated to these pools.
>> This delivered a usage of only a few MB. Of course I am aware that the
>> process consumes additional memory for stack, static data and text
>> segments, but this usage should be static.
>>
>> Is there any heap usage by httpd that I could have missed?
>>
>> - We do not use the unmanaged pools from APR. So I should have caught all
>> pools.
>> - I do no think that we use allocators that are not used by a pool. Hence I
>> should have caught all allocators and
>>   its free lists.
>> - As no request was processed when I captured the core (all worker threads
>> were waiting for work) I doubt that missed
>>   any or at least large memory consuming buckets.
>
> Is APR configured to return memory to the OS? Otherwise you might just see 
> all the allocated memory in the free list of the pool allocator(s).
>

MaxMemFree is set to 2 MB in httpd and the allocator free list's that I have 
checked do not contain much memory (around
400 KB in total for all of them).

Regards

Rüdiger

.gdbinit changes backports. CTR or RTC?

[Plüm , Rüdiger , Vodafone Group]

Is backporting .gdbinit changes to a stable branch CTR or RTC?

Regards

Rüdiger

AW: C-L filter buffering snafu

[Plüm , Rüdiger , Vodafone Group]

Just put a reply in bugzilla 
(https://bz.apache.org/bugzilla/show_bug.cgi?id=61222#c4),
plus a patch proposal. Reilly weird that we have not been hit by this for such 
a long
time. I think we should not buffer.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Joe Orton [mailto:jor...@redhat.com]
> Gesendet: Montag, 11. September 2017 19:33
> An: dev@httpd.apache.org
> Betreff: C-L filter buffering snafu
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61222
> 
> I may be missing something here, ap_content_length_filter looks broken.
> Currently it implements an unlimited size buffer, by trying to morph
> every indeterminate length bucket into the heap.  It has the standard
> "read till it blocks then flush" logic, but this isn't a defence against
> RAM consumption!
> 
> If the (e.g) CGI script is fast enough that read()s never block it just
> keeps on sucking up HEAP buckets, as the simple repro case in the bug
> shows.
> 
> 1. am I being stupid here?
> 
> 2. otherwise, is there a good defence of why that filter should buffer
> to try to compute a C-L - exactly how much it should buffer & why?!
> 
> Regards, Joe

AW: CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

[Plüm , Rüdiger , Vodafone Group]

http://svn.apache.org/r1800955

Regards

Rüdiger

Von: Rashmi Srinivasan [mailto:rashmisrinivasan2...@gmail.com]
Gesendet: Montag, 17. Juli 2017 07:50
An: dev@httpd.apache.org
Cc: us...@httpd.apache.org
Betreff: Re: CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

Hi,

Please can you point us to the patch for this CVE?

regards,
Rashmi

On Thu, Jul 13, 2017 at 6:32 PM, William A Rowe Jr 
> wrote:
CVE-2017-9788: Uninitialized memory reflection in mod_auth_digest

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
all versions through 2.2.33 and 2.4.26

Description:
The value placeholder in [Proxy-]Authorization headers
of type 'Digest' was not initialized or reset
before or between successive key=value assignments.
by mod_auth_digest
Providing an initial key with no '=' assignment
could reflect the stale value of uninitialized pool
memory used by the prior request, leading to leakage
of potentially confidential information, and a segfault

Mitigation:
All users of httpd should upgrade to 2.4.27 (or minimally
2.2.34, which will receive no further security releases.)
Alternately, the administrator could configure httpd to
reject requests with a header matching a complex regular
expression identifing where = character does not occur
in the first key=value pair, as in the following syntax;
[Proxy-]Authorization: Digest key[,key=value]

Credit:
The Apache HTTP Server security team would like to thank Robert Święcki
for reporting this issue.

References:
https://httpd.apache.org/security_report.html

AW: mod_proxy_fcgi and flush

[Plüm , Rüdiger , Vodafone Group]

Von: Luca Toscano [mailto:toscano.l...@gmail.com]
Gesendet: Freitag, 14. Juli 2017 11:30
An: Apache HTTP Server Development List 
Betreff: Re: mod_proxy_fcgi and flush

Hi Yann,

2017-07-13 22:15 GMT+02:00 Yann Ylavic 
>:
On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano 
> wrote:
>
> 1) read the FCGI headers to gather how much data the record is carrying
> (clen)
> 2) read the data in iobuf_size batches, sending each time the bytes
> collected to the output filter chain.
> 3) finally read the padding bytes (if any).
>
> I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> returned immediately most of the times due to the padding bytes ready to
> read (took me a while to realize this simple thing).

I forgot some details about proxy_fcgi so am asking before (re)looking at it :p

Can't we poll() after 3) ?
If so, maybe we could flush only if a small/zero timeout poll() times
out, and hence still be able to coalesce multiple (closed) records.

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch 
created, I tested it quickly and it seems working fine (still unsure about 
using r->connection->pool vs conn->pool in palloc). More tests following in the 
weekend :)

r->pool is the correct pool to use.

Regards

Rüdiger

Thanks for the hint!

Luca

AW: rfc1123 aka Proxy balancer://127

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:j...@jagunet.com]
> Gesendet: Montag, 10. Juli 2017 15:33
> An: dev@httpd.apache.org
> Betreff: Re: rfc1123 aka Proxy balancer://127
> 
> Personally, I think we simply document that balancer names
> must start w/ a character.

+1

Regards

Rüdiger

> 
> > On Jul 10, 2017, at 2:56 AM, jean-frederic clere 
> wrote:
> >
> > Hi,
> >
> > According rfc1123 the configuration:
> > ProxyPass "/" "balancer://127"
> > 
> >BalancerMember ajp://tomcat1:8009
> >BalancerMember ajp://tomcat2:8009
> > 
> >
> > 127 looks valid but it is rejected by httpd, apr_parse_addr_port()
> takes
> > 127 as port instead hostname.
> >
> > So addr is NULL, then I have:
> > "AH01157: error parsing URL //127: Invalid host/port"
> >
> > Is 127 really valid, if yes do we plan to fix that?
> >
> > Cheers
> >
> > Jean-Frederic

AW: mod_proxy_fcgi and flush

[Plüm , Rüdiger , Vodafone Group]

Von: Luca Toscano [mailto:toscano.l...@gmail.com]
Gesendet: Samstag, 8. Juli 2017 09:52
An: Apache HTTP Server Development List 
Betreff: Re: mod_proxy_fcgi and flush

Hi Jacob, Helmut!

2017-07-06 20:54 GMT+02:00 Jacob Champion 
>:
On 07/06/2017 11:13 AM, Jim Jagielski wrote:
works 4 me...

Doesn't for me. E.g. with a script like



it takes 1 second to receive a single chunk with both lines in it.

From a quick skim I assume this is because we don't use nonblocking sockets in 
the proxy implementation. (There's even a note in mod_proxy_fcgi that says, 
"Yes it sucks to [get the actual data] in a second recv call, this will 
eventually change when we move to real nonblocking recv calls.")

Quick check from my side too, so not sure if it makes sense. IIUC the comment 
is about getting all the headers from the FCGI backend (get_data_full(..., 
AP_FCGI_HEADER_LEN)), then get the response body in another one (the [actual 
data]).

I checked mod_fcgi as Helmut suggested and it seems to me that the -flush 
feature is a simple "flush every data that you receive", so I tested the 
following patch with Jacob's php example code and it seems doing what Helmut 
asked (please correct me if I am wrong).

Caveat: I had to set output_buffering = Off in my php-fpm's php.ini config file.

http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush.patch

Flushing unconditionally is a bad idea performance wise. Please have a look how 
ajp solved this issue:

https://svn.apache.org/r327185
https://svn.apache.org/r384580
https://svn.apache.org/r390210
https://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_ajp.c?r1=325879=390210

Hint: The above diff contains further unrelated changes.

Regards

Rüdiger

AW: svn commit: r1800181 - /httpd/httpd/branches/2.4.x/STATUS

[Plüm , Rüdiger , Vodafone Group]

FWIW: I am fine with Yann’s proposal as well.

Regards

Rüdiger

Von: William A Rowe Jr [mailto:wr...@rowe-clan.net]
Gesendet: Mittwoch, 28. Juni 2017 19:28
An: httpd 
Cc: c...@httpd.apache.org
Betreff: Re: svn commit: r1800181 - /httpd/httpd/branches/2.4.x/STATUS

Actually, I should have backed out rpluem's vote for the original one line 
patch.

Can we get one more pair of eyeballs (or cross-vote the other branch) so this 
is properly accepted?


On Jun 28, 2017 10:49, > wrote:
Author: ylavic
Date: Wed Jun 28 15:49:07 2017
New Revision: 1800181

URL: http://svn.apache.org/viewvc?rev=1800181=rev
Log:
Vote, promote.

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=1800181=1800180=1800181=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Wed Jun 28 15:49:07 2017
@@ -116,6 +116,15 @@ RELEASE SHOWSTOPPERS:
 PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
   [ start all new proposals below, under PATCHES PROPOSED. ]

+   *) Restore single-char field names inadvertantly disallowed in 2.4.25.
+  Message ID: 

AW: Timeouts and other time-related granularity

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Dienstag, 20. Juni 2017 15:13
> An: dev@httpd.apache.org
> Betreff: Re: Timeouts and other time-related granularity
> 
> 
> > Am 20.06.2017 um 14:56 schrieb Jim Jagielski :
> >
> > Most of our time-related directives accept seconds as their
> > parameters, but I'm thinking that allowing milliseconds is
> > likely a better option... From what I can see, most of what
> > would be interesting/useful to change are stored as interval/apr_time
> > anyway, so there would be no real API/struct changes required.
> >
> > Thoughts? Comments?
> 
> +1
> 
> I would suggest a common duration syntax for better readability and a
> common conversion util function. We can stick to seconds if it is
> just a number, but allow fractions for millis etc. So
> 
> "1" is 1 second "0.001" is one millisecond, as is "1ms".
> "1.5m" is 90 seconds, as is "1:30m"
> "1:15h" is 75 minutes
> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms.
> "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc.

We already have such a similar function used in various places of the config:

/**
 * Parse a given timeout parameter string into an apr_interval_time_t value.
 * The unit of the time interval is given as postfix string to the numeric
 * string. Currently the following units are understood:
 *
 * ms: milliseconds
 * s : seconds
 * mi[n] : minutes
 * h : hours
 *
 * If no unit is contained in the given timeout parameter the default_time_unit
 * will be used instead.
 * @param timeout_parameter The string containing the timeout parameter.
 * @param timeout The timeout value to be returned.
 * @param default_time_unit The default time unit to use if none is specified
 * in timeout_parameter.
 * @return Status value indicating whether the parsing was successful or not.
 */
AP_DECLARE(apr_status_t) ap_timeout_parameter_parse(
   const char *timeout_parameter,
   apr_interval_time_t *timeout,
   const char *default_time_unit);

Regards

Rüdiger

AW: ocsp stapling improvements

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Dienstag, 20. Juni 2017 13:40
> An: dev@httpd.apache.org
> Betreff: Re: ocsp stapling improvements
> 
> 
> > Am 12.06.2017 um 21:35 schrieb Ruediger Pluem :
> >
> > I guess the core mistake we do today is that we expire the entries in
> the cache
> > after SSLStaplingStandardCacheTimeout. But we should keep them in the
> cache as long as
> > they are valid (so either whats in the next update field of the
> response or this update
> > + SSLStaplingResponseMaxAge).
> 
> +1
> 
> > Instead we should have a refresh parameter that I would set as
> percentage of the
> > expired time (so between this update and next update or as percentage
> of already
> > expired SSLStaplingResponseMaxAge). Once this refresh time is passed
> OCSP responses
> > should get refreshed by a background job (possibly implemented by
> mod_watchdog).
> 
> +1
> 
> >> 2. Persist responses (is this just a config/default issue?)
> >
> > This could become tricky given the various so cache implementations we
> have. I could
> > only think of persisting the whole cache when Apache is shutdown.
> 
> I am not very experienced with those. Would the current Stapling
> implementation not work with a "socache_dbm"? And what would be the
> drawback of that?

It might cause I/O overhead compared with socache_shmcb, but it might be a good 
solution
for those who want to have persisted OCSP responses. Other people might priorize
a distributed cache like dc or memcache. So I like the idea of just staying
with the current approach to define the socache provider used for caching.
Who knows? Maybe someone writes a socache_staggered that allows to go through 
several
socache providers one after another in case of a cache miss? That would allow 
to have
a shmcb first and a dbm second.

> 
> As an alternative, use of mod_watchdog offers advantages here. If we
> have only one thread (for all or for a particular certificate) that
> writes the cache in a server (all processes), it becomes easy to use the
> file system, I think. Write per tmpfile+rename should be good enough and
> it should no longer need a global mutex. Server names are distinct and
> make for an easy directory tree.
> 
> The question then is if mod_watchdog jobs still have privileges or if
> those files have common ownership and if that is a problem.
> 
> Does this makes sense or am I insane?

I guess this is all solvable, but as stated above I am in favor of just using 
the
socache API for that and let our requirements be solved by an appropriate 
socache
provider.

> 
> >> 3. Start update responses at server start/regular intervals
> >
> > What I want to avoid is that the server "hangs" at start because of a
> "hanging" OCSP server.
> > I admit that this can happen already today on the very first SSL
> request with stapling turned
> > on, but IMHO this is a bad behavior. So either just do the stuff on a
> regular basis in the background
> > and do not staple if there is no valid OCSP response yet (I know Hanno
> won't like that :-))
> > Or have an initial (valid) OCSP response being loaded from a file
> during startup. It would be up to
> > the admin to fill this file with a valid OCSP response before it
> starts httpd.
> 
> Can we push the burden of getting a OCSP response to the client, even
> for must-staple certificates? This would be nice as a fall back in case
> of errors. The error might be in the data center for outgoing
> connections, so the client might succeed where the server fails.

I would be in favor of this. I think it is still reasonable to have the client
try the OCSP server if the server cannot get a valid response to staple.
But this is my personal opinion, so others might have different requirements.
The question to me is what do we need to do in mod_ssl code to offer this?
I mean the changes that are now on the table should ensure that we get a more
reliable stapling infrastructure within mod_ssl that allows people to try
must-staple. Anything else we need or can do?

Regards

Rüdiger

AW: The drive for 2.4.26

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Dienstag, 6. Juni 2017 10:40
> An: dev@httpd.apache.org
> Betreff: Re: The drive for 2.4.26
> 
> Proposed the patch as fix, since we did not see the behaviour pop up
> again over the last days at Steffen's system.
> 
> I assume the RTC is in place now.

My personal opinion: Only after 2.4.26 is released. So from my personal point 
of view you can go ahead backporting.
Others may see this differently.

Regards

Rüdiger

> 
> -Stefan
> 
> > Am 06.06.2017 um 09:26 schrieb Stefan Eissing
> :
> >
> > I made a patch on Friday evening for Steffen's system where the
> behaviour happens. Hope to hear back from him today.
> >
> > -Stefan
> >
> >> Am 06.06.2017 um 03:12 schrieb Eric Covener :
> >>
> >> On Tue, May 30, 2017 at 9:12 AM, Stefan Eissing
> >>  wrote:
> >>> I have one report of a CPU busy loop that seems to only happen on
> the last 3 changes in mod_http2. Steffen is currently testing if a
> feature disable solves the problem and thus points to the cause. I hope
> to hear from him tomorrow sometime during the day if that addresses the
> issue or not.
> >>>
> >>> Otherwise I am hesitant to make any more changes from my side and
> hope we can go forward with a release.
> >>
> >>
> >> Anything on this?
> >>
> >> --
> >> Eric Covener
> >> cove...@gmail.com
> >

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

[Plüm , Rüdiger , Vodafone Group]

Shouldn't we call apr_brigade_cleanup in any case after ap_pass_brigade?

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 27. April 2017 11:47
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
> 
> On Wed, Apr 26, 2017 at 11:26 AM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> wrote:
> >
> >> Am 26.04.2017 um 11:14 schrieb Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com>:
> >>
> >>
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> >>> Gesendet: Mittwoch, 26. April 2017 10:55
> >>> An: dev@httpd.apache.org
> >>> Betreff: Re: svn commit: r1707087 -
> >>> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
> >>>
> >>> Eh, not really into mod_bucketeer and its use cases, but some
> >>> observations after a quick scan:
> >>>
> >>> line 99:
> >>>rv = ap_pass_brigade(f->next, ctx->bb);
> >>>apr_brigade_cleanup(ctx->bb);
> >>>
> >>> line 146:
> >>>rv = ap_pass_brigade(f->next, ctx->bb);
> >>>if (rv) {
> >>>return rv;
> >>>}
> >>>apr_brigade_cleanup(ctx->bb);
> >>>
> >>> such things only work if an EOS always comes *before* an EOR
> >>> bucket (case 1) or of no DATA bucket of any kind follows an EOR.
> >>
> >> Correct, but with the BUCKETEER filter being a resource filter that
> >> should not happen.
> >
> > Because the implementations of everything else in the server do not
> > do it? Should we then add a filter that checks exactly that?
> 
> I don't think that EOR before EOS can happen in HTTP/1, because
> ap_finalize_request_protocol() is always called before
> ap_process_request_after_handler().
> 
> EOS is the signal for request filters to get out of the way, so this
> is probably what ap_request_core_filter() should do too, and the
> purpose of the attached patch.
> This patch could use EOR instead, but I find EOS more "semantically"
> correct for a request filter (we don't need to set aside anything
> after it), while EOR would be crash safe only...
> 
> Jacob, does it work better?
> 
> 
> Regards,
> Yann.

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

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Stefan Eissing [mailto:stefan.eiss...@greenbytes.de]
> Gesendet: Mittwoch, 26. April 2017 10:55
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
> 
> Eh, not really into mod_bucketeer and its use cases, but some
> observations after a quick scan:
> 
> line 99:
> rv = ap_pass_brigade(f->next, ctx->bb);
> apr_brigade_cleanup(ctx->bb);
> 
> line 146:
> rv = ap_pass_brigade(f->next, ctx->bb);
> if (rv) {
> return rv;
> }
> apr_brigade_cleanup(ctx->bb);
> 
> such things only work if an EOS always comes *before* an EOR bucket
> (case 1)
> or of no DATA bucket of any kind follows an EOR.

Correct, but with the BUCKETEER filter being a resource filter that should
not happen.

Regards

Rüdiger

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

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Jacob Champion [mailto:champio...@gmail.com]
> Gesendet: Mittwoch, 26. April 2017 00:23
> An: dev@httpd.apache.org; Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com>
> Betreff: Re: AW: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
> 
> On 02/15/2017 10:10 AM, Plüm, Rüdiger, Vodafone Group wrote:
> > How about creating it from c->pool and storing it in c->notes for the
> lifetime
> > of c?
> 
> Would that be unsafe for HTTP/2? Can multiple requests (that use
> ap_request_core_filter) be active on the same connection at once?

IMHO ap_request_core will use different slave connections then.
Stefan may prove me wrong, but we still won't have more than one request
in processing at the same time per slave connection

Regards

Rüdiger

AW: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./ CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c

[Plüm , Rüdiger , Vodafone Group]

I guess the patch is fine with one exception: Please do not "recycle" a 
configuration option
setup explicitly for another module (flusher for mod_proxy_fdpass) for your 
patch. This only creates
confusion. Please create a new one and document it.

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: jean-frederic clere [mailto:jfcl...@gmail.com]
> Gesendet: Mittwoch, 19. April 2017 10:42
> An: dev@httpd.apache.org
> Betreff: Re: svn commit: r1674661 - in /httpd/httpd/branches/2.4.x: ./
> CHANGES STATUS modules/proxy/mod_proxy_wstunnel.c
> 
> On 03/02/2017 12:50 PM, Eric Covener wrote:
> > Curious about the headers in the bug report / recreate.
> 
> I have looked to the problem again I have 2 JIRA related to the commit:
>  https://issues.jboss.org/browse/JBCS-254
>  https://issues.jboss.org/browse/JBCS-291
> 
> Basically people using mod_proxy_wstunnel with jboss-remoting and
> HTTP/1.1 + upgrade WebSocket.
> 
> For the jboss-remoting: (httpd to server)
> GET / HTTP/1.1
> 
> Host: localhost:8080
> 
> Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
> 
> X-Forwarded-For: 127.0.0.1
> 
> X-Forwarded-Host: localhost:8282
> 
> X-Forwarded-Server: fe80::56ee:75ff:fe1d:45fb
> 
> Upgrade: jboss-remoting
> 
> Connection: Upgrade
> 
> 
> 
> HTTP/1.1 101 Switching Protocols
> 
> Connection: Upgrade
> 
> Upgrade: jboss-remoting
> 
> Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
> 
> Date: Wed, 19 Apr 2017 08:01:18 GMT
> 
> 
> client to proxy:
> GET / HTTP/1.1
> 
> Sec-JbossRemoting-Key: NGELpfuU01no5ZPM9705Fg==
> 
> Upgrade: jboss-remoting
> 
> Host: localhost:8282
> 
> Connection: upgrade
> 
> 
> 
> HTTP/1.1 101 Switching Protocols
> 
> Connection: Upgrade
> 
> Upgrade: jboss-remoting
> 
> Sec-JbossRemoting-Accept: QR2l+ma75tZ4T1yrrJ/wxNwDPwg=
> 
> Date: Wed, 19 Apr 2017 08:01:18 GMT
> 
> 
> 
> ...
> 
> 
> The HTTP/1.1 + upgrade: (basically it get the websocket app using
> HTTP/1.1 and then)
> GET /jboss-websocket-hello/websocket/helloName HTTP/1.1
> 
> Host: localhost:8000
> 
> User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:52.0)
> Gecko/20100101 Firefox/52.0
> 
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> 
> Accept-Language: en-US,en;q=0.7,ca;q=0.3
> 
> Accept-Encoding: gzip, deflate
> 
> Sec-WebSocket-Version: 13
> 
> Origin: http://localhost:8000
> 
> Sec-WebSocket-Extensions: permessage-deflate
> 
> Sec-WebSocket-Key: IPPsC2JbqOS1QfWepOVnvQ==
> 
> Connection: keep-alive, Upgrade
> 
> Pragma: no-cache
> 
> Cache-Control: no-cache
> 
> Upgrade: websocket
> 
> 
> 
> HTTP/1.1 101
> 
> Upgrade: websocket
> 
> Connection: upgrade
> 
> Sec-WebSocket-Accept: PVBn1cxiXtjKaAeECRlpKv6lOaA=
> 
> Sec-WebSocket-Extensions: permessage-deflate
> 
> Date: Wed, 19 Apr 2017 08:17:36 GMT
> 
> 
> So I need 2 things:
> 1 - Upgrade to jboss-remoting.
> 2 - Proxy without the upgrade header.
> 
> To try something I have used:
> flusher=jboss-remoting (basically does the tunnel for another protocol)
> flusher=NONE (basically bypass the checks added by r1674661).
> 
> I don't think mod_proxy_fdpass will be used with mod_proxy_wstunnel and
> flusher looks like scheme for the size.
> 
> Any better suggestion before I commit the patch?
> 
> Cheers
> 
> Jean-Frederic
> 
> >
> > On Thu, Mar 2, 2017 at 6:31 AM, Jim Jagielski  wrote:
> >>
> >>> On Mar 2, 2017, at 5:58 AM, jean-frederic clere 
> wrote:
> >>>
> 
>  +upgrade = apr_table_get(r->headers_in, "Upgrade");
>  +if (!upgrade || strcasecmp(upgrade, "WebSocket") != 0) {
>  +ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
> APLOGNO(02900)
>  +  "declining URL %s  (not WebSocket)", url);
>  +return DECLINED;
> >>>
> >>> In fact this causing regression for some customer, could we make
> that
> >>> switch able? See https://issues.jboss.org/browse/JBCS-291
> >>>
> >>
> >> Sure!
> >>
> >
> >
> >

AW: [RFC] ?

[Plüm , Rüdiger , Vodafone Group]

+1

Regards

Rüdiger

> -Ursprüngliche Nachricht-
> Von: Joe Orton [mailto:jor...@redhat.com]
> Gesendet: Mittwoch, 8. März 2017 11:30
> An: dev@httpd.apache.org
> Betreff: Re: [RFC] ?
> 
> On Tue, Mar 07, 2017 at 11:52:17AM -0800, Jacob Champion wrote:
> > On 02/28/2017 04:32 PM, Jacob Champion wrote:
> > > I just don't like hamstringing a nice new directive with what's
> > > effectively a (rare) bug.
> >
> > (The conversation kinda died shortly after I said this. That was not
> my
> > intent -- I like this directive a lot. Whether the consensus is to
> keep the
> > corner case, or introduce a new  or , or make
> the
> > arg quotable, or whatever. I don't mean to be throwing up roadblocks.)
> 
> Sorry, taking my time here, and I appreciate all the feedback.
> Definitely happier to debate it and get it right than be lumbered with
> annoying edge cases forever.
> 
> I did the refactoring in r1785943, so third iteration attached has both
>  and .  I'd have been fine with either
> previous iteration, but this does make sense to me.
> 
> Final call for yay/nay?
> 
> Regards, Joe

AW: httpd 2.4.25, mpm_event, ssl: segfaults

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 16. Februar 2017 11:35
> An: httpd-dev <dev@httpd.apache.org>
> Betreff: Re: httpd 2.4.25, mpm_event, ssl: segfaults
> 
> On Thu, Feb 16, 2017 at 11:20 AM, Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com> wrote:
> >>
> >> Please note that "EnableMMap on" avoids EnableSendfile (i.e.
> >> "EnableMMap on" => "EnableSendfile off")
> >
> > Just for clarification: If you placed EnableMMap on in your test
> > configuration you also put EnableSendfile off in your configuration,
> > correct? Just putting in EnableMMap on does not automatically cause
> > EnableSendfile set to off. I know that at least on trunk
> > EnableSendfile on is no longer the default.
> 
> If I "EnableMMap on", core_output_filter() will never use sendfile()
> (whatever EnableSendfile is).
> 
> I can try to figure out why (that's a really-all build/conf, so maybe
> some module's filter is apr_bucket_read()ing in the chain unless
> EnableMMap, unlikely though)...

And this is what I don't understand and cannot read immediately from the code. 
Weird.


Regards

Rüdiger

AW: httpd 2.4.25, mpm_event, ssl: segfaults

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Donnerstag, 16. Februar 2017 10:49
> An: httpd-dev 
> Betreff: Re: httpd 2.4.25, mpm_event, ssl: segfaults
> 
> Here are some SSL/core_write outputs (sizes) for me, with 2.4.x.
> This is with a GET for a 2MB file, on localhost...
> 
> Please note that "EnableMMap on" avoids EnableSendfile (i.e.
> "EnableMMap on" => "EnableSendfile off"), which is relevant only in

Just for clarification: If you placed EnableMMap on in your test configuration 
you also put
EnableSendfile off in your configuration, correct? Just putting in EnableMMap 
on does not automatically
cause EnableSendfile set to off. I know that at least on trunk EnableSendfile 
on is no longer the default.


Regards

Rüdigef

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

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Mittwoch, 15. Februar 2017 14:08
> An: httpd-dev 
> Betreff: Re: svn commit: r1707087 -
> /httpd/httpd/trunk/modules/debugging/mod_bucketeer.c
> 
> [with the patch]
> 
> On Wed, Feb 15, 2017 at 2:07 PM, Yann Ylavic 
> wrote:
> > On Tue, Feb 14, 2017 at 10:21 PM, Jacob Champion
>  wrote:
> >>
> >
> > , hence the (default_)handler probably returned
> >>
> >>> Admittedly bucketeer_out_filter() is not very nice because it does
> not
> >>> "consume" its given brigade (nor does default_handler() clear it
> >>> afterward), but that shouldn't be an issue since anyway nothing
> should
> >>> use them once the request is destroyed.
> >>>
> >>> Do you have a backtrace of the crash (and/or a breakpoint in
> >>> bucketeer_out_filter() for the test)?
> >>
> >>
> >> Attached.
> >
> > Thanks, it shows the request being destroyed with the EOR bucket.
> > However the brigade containing the EOR is also allocated on r->pool,
> > hence remove_empty_buckets()'s loop crashes (AIUI).
> >
> > Here is the (reverse) backtrace:
> >
> > #17 0x00488070 in ap_process_request_after_handler
> > (r=0x7fa70980d0a0) at modules/http/http_request.c:366
> > #16 0x0043a4d6 in ap_pass_brigade (next=0x7fa70981b7d0,
> > bb=0x7fa7097fe088) at server/util_filter.c:610
> > [...]
> > #8  0x004554ca in ap_request_core_filter (f=0x7fa70980ea78,
> > bb=0x7fa7097fe088) at
> > #7  0x0043a4d6 in ap_pass_brigade (next=0x7fa709821cc0,
> > bb=0x7fa709821c80) at server/util_filter.c:610
> > [...]
> > #2  0x004579c0 in ap_core_output_filter (f=0x7fa7097fdcc8,
> > bb=0x7fa709821c80) at server/core_filters.c:467
> > #1  0x00457b32 in send_brigade_nonblocking (s=0x7fa7098250b0,
> > bb=0x7fa709821c80, bytes_written=0x7fa7097fe040, c=0x7fa709825348) at
> > server/core_filters.c:511
> > #0  0x00457f98 in remove_empty_buckets (bb=0x7fa709821c80) at
> > server/core_filters.c:604
> >
> > See how frame #8 changes "bb" to its own "tmp_bb" (allocated on r-
> >pool).
> > Since ap_request_core_filter() is trunk only (r1706669), it also
> > explains why it does not happen in 2.4.x.
> >
> > Does the attached patch work for you?
> > I don't like it too much (if ever relevent), we could also possibly
> > special case the EOR brigade (looks a bit hacky to me) or create
> > tmp_bb on c->pool (and leak a few bytes per request, like
> > ap_process_request_after_handler() already)...

How about creating it from c->pool and storing it in c->notes for the lifetime
of c?

Regards

Rüdiger

AW: ssl_io_filter_output vs EOC

[Plüm , Rüdiger , Vodafone Group]

> -Ursprüngliche Nachricht-
> Von: Yann Ylavic [mailto:ylavic@gmail.com]
> Gesendet: Freitag, 3. Februar 2017 18:06
> An: httpd-dev 
> Betreff: ssl_io_filter_output vs EOC
> 
> Besides metadata buckets, should the EOC semantic really apply to the
> ssl output filter?
> 
> It's not really an issue by now because we never send "data" buckets
> after an EOC, but should this happen do we really want to send them
> out in clear, after the TLS close notify?
> 
> I'd rather be safe here and return an error up the filters' stack.
> Actually this is what is done already if the data come in the same
> brigade as the EOC (ssl_filter_write() in the same loop will fail when
> the TLS connection is shutdown), but for subsequent brigade(s) we'd
> pass through (per EOC semantic).
> 
> This at least requires a consistency "fix" (for the theory, I can't
> think of any pratical/reasonable use of data buckets after EOC, e.g.
> an Upgrade from TLS to clear looks really hazardous...).
> 
> Is it unacceptable to add an exception to the EOC semantic (for data)
> here and fail (as sanity check)?

IMHO we currently fail after we processed an EOC (no matter if in the same 
brigade or in a follow up brigade)
and we should continue doing so.

Regards

Rüdiger