Re: JSON for mod_status

[Stefan Eissing]

> Am 02.12.2016 um 06:06 schrieb PKU.孙斌 :
> 
> As to accept headers, that's a pain in the butt if someone just wants to grab 
> a copy of the data for debugging a custom parser or something.  So much 
> easier to just wget BLAH than to mess with the accept headers on any utility 
> we want to fetch with.

I see the point of Accept-* header triggering representation, but there should 
always be a URL for each format that sends that one format all the time.

-Stefan

Re: JSON for mod_status

[Stefan Eissing]

> Am 01.12.2016 um 23:14 schrieb Jim Jagielski :
> 
> 
>> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr  wrote:
>> 
>> 
>> Note that mod_bmx_status entries focus on what most management
>> frameworks are looking for, so thus far, it doesn't deliver an entire
>> dataset per connection or worker thread. It certainly could, of course.
> 
> Nor does it expose anything from any other beans created
> by any other module.
> 
> Can it?
> 
> If so, exactly how.
> 
>> 
>> Again, it simply iterates the entire contents of each bean presented
>> to it's own print_bean_fn callback. If you have a look at;
>> https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx.h
>> that should give you a somewhat higher altitude perspective on Aaron's
>> API design.
> 
> So mod_bmx_status has to query mod_bmx for "all beans" ??

It seems to me from the name of the callback that this is for "printing" stuff, 
either all or only the name matching (which is probably a URL parameter. Fair 
enough. 

But as Jim pointed out, it would be more powerful if one could
a) detect which beans are potentially available
b) retrieve and aggregate them

So, we'd have BeanProviders that take over a namespace. They register at server 
start.

ProviderRegistry["proxy/balancer"] -> registered provider hook by the module
ProviderRegistry["proxy/type/h2"]-> registered provider hook by 
mod_proxy_http2
ProviderRegistry["proxy/type/h2c"]   -> registered provider hook by 
mod_proxy_http2

One can query this registry.

For lookups, there is a BeanContext that caches beans once retrieved. So there 
is not need to look them up again in the same request. That is passed to all 
registered bean provider queries, so that providers can also query for other 
beans while assembling their own.

A bean produced this way is then send to the client in the requested format 
using a standard set of BeanToJSON, BeanToXML, BeanToHTML serializers. The 
beans just need to be a slim wrapper around 
apr_table_t/apr_array_header_t/const char*/int/apr_size_t/apr_off_t/double.

The registry can be mapped to URL space, so 
 * https://localhost/status/proxy/balancer would list the bean there,
 * https://localhost/status/proxy/type would list all beans registered with 
that prefix.

-Stefan

Re: [Bug 60439] New: Program terminated with signal SIGSEGV, Segmentation fault.

[Stefan Eissing]

This does not look right:

> Am 02.12.2016 um 10:49 schrieb bugzi...@apache.org:
> 
> #9  ap_core_output_filter (f=0x0, new_bb=0x7f5dac10c980) at
> /opt/build/unpack/httpd-2.4.23/server/core_filters.c:542
>c = 0x7f5dac10c3e8
>bytes_in_brigade = 0
>non_file_bytes_in_brigade = 0
>eor_buckets_in_brigade = 1678275960
>morphing_bucket_in_brigade = 8152

Re: JSON for mod_status

[William A Rowe Jr]

On Thu, Dec 1, 2016 at 4:14 PM, Jim Jagielski  wrote:

>
> > On Dec 1, 2016, at 2:16 PM, William A Rowe Jr 
> wrote:
> >
> >
> > Note that mod_bmx_status entries focus on what most management
> > frameworks are looking for, so thus far, it doesn't deliver an entire
> > dataset per connection or worker thread. It certainly could, of course.
>
> Nor does it expose anything from any other beans created
> by any other module.
>
> Can it?
>
> If so, exactly how.
>
> >
> > Again, it simply iterates the entire contents of each bean presented
> > to it's own print_bean_fn callback. If you have a look at;
> > https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx.h
> > that should give you a somewhat higher altitude perspective on Aaron's
> > API design.
>
> So mod_bmx_status has to query mod_bmx for "all beans" ??
>

You are still thinking upside down. Think of mod_bmx as the data sink
and mod_bmx_status as the data source. mod_bmx_status doesn't look
at anything except the internals of httpd. Nobody queries mod_bmx_status
directly except mod_bmx. The user agent queries mod_bmx.

Re: JSON for mod_status

[William A Rowe Jr]

On Fri, Dec 2, 2016 at 3:28 AM, Stefan Eissing  wrote:

>
> > Am 01.12.2016 um 23:14 schrieb Jim Jagielski :
> >
> >
> >> On Dec 1, 2016, at 2:16 PM, William A Rowe Jr 
> wrote:
> >>
> >>
> >> Note that mod_bmx_status entries focus on what most management
> >> frameworks are looking for, so thus far, it doesn't deliver an entire
> >> dataset per connection or worker thread. It certainly could, of course.
> >
> > Nor does it expose anything from any other beans created
> > by any other module.
> >
> > Can it?
> >
> > If so, exactly how.
> >
> >>
> >> Again, it simply iterates the entire contents of each bean presented
> >> to it's own print_bean_fn callback. If you have a look at;
> >> https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx.h
> >> that should give you a somewhat higher altitude perspective on Aaron's
> >> API design.
> >
> > So mod_bmx_status has to query mod_bmx for "all beans" ??
>
> It seems to me from the name of the callback that this is for "printing"
> stuff, either all or only the name matching (which is probably a URL
> parameter. Fair enough.
>
> But as Jim pointed out, it would be more powerful if one could
> a) detect which beans are potentially available
>

+1. This is possible today simply by requesting 'all'. But an actual
query of modules and property names exposed across the entire
bean factory would be very interesting.


> b) retrieve and aggregate them
>

We can on a 1:1 basis today (either an entire module scope, or only
named properties across all modules, or all of the above.)

It would be nice to enhance this as a many:1 response of several
targeted data points desired.

So, we'd have BeanProviders that take over a namespace. They register at
> server start.
>
> ProviderRegistry["proxy/balancer"] -> registered provider hook by the
> module
> ProviderRegistry["proxy/type/h2"]-> registered provider hook by
> mod_proxy_http2
> ProviderRegistry["proxy/type/h2c"]   -> registered provider hook by
> mod_proxy_http2
>
> One can query this registry.
>

One would also register the Property names exposed by the provider, no?


> For lookups, there is a BeanContext that caches beans once retrieved. So
> there is not need to look them up again in the same request. That is passed
> to all registered bean provider queries, so that providers can also query
> for other beans while assembling their own.
>
> A bean produced this way is then send to the client in the requested
> format using a standard set of BeanToJSON, BeanToXML, BeanToHTML
> serializers. The beans just need to be a slim wrapper around
> apr_table_t/apr_array_header_t/const char*/int/apr_size_t/apr_off_
> t/double.
>
> The registry can be mapped to URL space, so
>  * https://localhost/status/proxy/balancer would list the bean there,
>  * https://localhost/status/proxy/type would list all beans registered
> with that prefix.
>

The current syntax is;

https://localhost/status/?proxy_balancer
;*
https://localhost/status/?proxy_balancer
;Pool=app1,State=Error

etc.

I'd have no issue with enhancing this to support your proposed syntax.
As the already adopted backend of one or more management agents,
I'd like to see us continue to accept the existing syntax. Use whichever
is most appropriate.

The existing design expects the provider to choose a name once and
remain consistent. So even as new property/value pairs can be added,
the behavior of existing ones remains consistent. Otherwise the interface
would have no value to a management agent / snmp replacement.

Bill

Re: svn commit: r1772339 - /httpd/test/framework/trunk/t/conf/extra.conf.in

[William A Rowe Jr]

On Fri, Dec 2, 2016 at 6:06 AM,  wrote:

> Author: jim
> Date: Fri Dec  2 12:06:30 2016
> New Revision: 1772339
>
> URL: http://svn.apache.org/viewvc?rev=1772339&view=rev
> Log:
> This isn't in 2.4.24, yet.
>

Hmmm. Looks like a good case to be made for implementing
AP_AC_HAVE_DIRECTIVE()

/ducks

Re: Random AH01842 errors in mod_session_crypto

[Yann Ylavic]

On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic  wrote:
>
> Patch attached, WDYT?

Ping, probably is worth considering for 1.6 (even 1.5) ?

>
> Regards,
> Yann.

Re: Random AH01842 errors in mod_session_crypto

[William A Rowe Jr]

On Fri, Dec 2, 2016 at 3:06 PM, Yann Ylavic  wrote:

> On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic  wrote:
> >
> > Patch attached, WDYT?
>
> Ping, probably is worth considering for 1.6 (even 1.5) ?
>

Provided you don't *break* the API contract with 1.x.x, corrections
can be applied to 1.(current). This looks like it falls in that category.

Things get wonky when you have duplicates-permitted and decide
that's bad, so change the behavior to duplicates-disallowed. That
would actually violate any 1.x release update.

But as long as we are conforming the behavior to the published
description, bug fixes are welcome.

Re: Time for 2.4.24!

[William A Rowe Jr]

On Thu, Dec 1, 2016 at 8:28 AM, Jim Jagielski  wrote:

> hello? hello? Anyone there? :)
>
> > On Nov 21, 2016, at 7:47 AM, Jim Jagielski  wrote:
> >
> > We have a few items in STATUS that, imo, should be tested, voted-on
> > and the committed to the httpd-2.4 branch in anticipation of a new
> > release SOON!
>

+1. There is a proposed mitigation of the many security defects intrinsic
in HTTP server implementations sitting in STATUS with one vote, I'd think
the project would want to correct this and any undisclosed vulnerabilities
in the queue prior to T&R. Sooner, the better.

Cheers,

Bill

Re: Random AH01842 errors in mod_session_crypto

[Yann Ylavic]

On Fri, Dec 2, 2016 at 10:06 PM, Yann Ylavic  wrote:
> On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic  wrote:
>>
>> Patch attached, WDYT?
>
> Ping, probably is worth considering for 1.6 (even 1.5) ?

Committed to APR trunk (r1772414), 1.6.x (r1772415) and 1.5.x (r1772416).

Regards,
Yann.

Re: Random AH01842 errors in mod_session_crypto

[William A Rowe Jr]

On Fri, Dec 2, 2016 at 4:28 PM, Yann Ylavic  wrote:

> On Fri, Dec 2, 2016 at 10:06 PM, Yann Ylavic  wrote:
> > On Wed, Oct 5, 2016 at 12:23 PM, Yann Ylavic 
> wrote:
> >>
> >> Patch attached, WDYT?
> >
> > Ping, probably is worth considering for 1.6 (even 1.5) ?
>
> Committed to APR trunk (r1772414), 1.6.x (r1772415) and 1.5.x (r1772416).
>

Excellent! Docs edits also welcome for clarification.

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[Eric Covener]

probably wiser ways to fix but I didn't want to sit on it.

On Fri, Dec 2, 2016 at 7:10 PM,   wrote:
> Author: covener
> Date: Sat Dec  3 00:10:31 2016
> New Revision: 1772418
>
> URL: http://svn.apache.org/viewvc?rev=1772418&view=rev
> Log:
> loop in checking response headers
>
> w/ HTTPProtocolOptions Unsafe
>
> Modified:
> httpd/httpd/trunk/modules/http/http_filters.c
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=1772418&r1=1772417&r2=1772418&view=diff
> ==
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Sat Dec  3 00:10:31 2016
> @@ -667,6 +667,7 @@ static int check_header(void *arg, const
>  /* Simply terminate scanning on a CTL char, allowing whitespace */
>  test = val;
>  do {
> +while (*test == ' ' || *test == '\t') test++;
>  test = ap_scan_vchar_obstext(test);
>  } while (*test == ' ' || *test == '\t');
>  }
>
>



-- 
Eric Covener
cove...@gmail.com

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

That is code I'm less familiar with, but will give it careful scrutiny
tomorrow.

On Fri, Dec 2, 2016 at 6:12 PM, Eric Covener  wrote:

> probably wiser ways to fix but I didn't want to sit on it.
>
> On Fri, Dec 2, 2016 at 7:10 PM,   wrote:
> > Author: covener
> > Date: Sat Dec  3 00:10:31 2016
> > New Revision: 1772418
> >
> > URL: http://svn.apache.org/viewvc?rev=1772418&view=rev
> > Log:
> > loop in checking response headers
> >
> > w/ HTTPProtocolOptions Unsafe
> >
> > Modified:
> > httpd/httpd/trunk/modules/http/http_filters.c
> >
> > Modified: httpd/httpd/trunk/modules/http/http_filters.c
> > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/
> http/http_filters.c?rev=1772418&r1=1772417&r2=1772418&view=diff
> > 
> ==
> > --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> > +++ httpd/httpd/trunk/modules/http/http_filters.c Sat Dec  3 00:10:31
> 2016
> > @@ -667,6 +667,7 @@ static int check_header(void *arg, const
> >  /* Simply terminate scanning on a CTL char, allowing whitespace
> */
> >  test = val;
> >  do {
> > +while (*test == ' ' || *test == '\t') test++;
> >  test = ap_scan_vchar_obstext(test);
> >  } while (*test == ' ' || *test == '\t');
> >  }
> >
> >
>
>
>
> --
> Eric Covener
> cove...@gmail.com
>

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

FWIW, did you actually fix this on truck and convey the backport
svn rev no?

On Fri, Dec 2, 2016 at 6:25 PM, William A Rowe Jr 
wrote:

> That is code I'm less familiar with, but will give it careful scrutiny
> tomorrow.
>
>
> On Fri, Dec 2, 2016 at 6:12 PM, Eric Covener  wrote:
>
>> probably wiser ways to fix but I didn't want to sit on it.
>>
>> On Fri, Dec 2, 2016 at 7:10 PM,   wrote:
>> > Author: covener
>> > Date: Sat Dec  3 00:10:31 2016
>> > New Revision: 1772418
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1772418&view=rev
>> > Log:
>> > loop in checking response headers
>> >
>> > w/ HTTPProtocolOptions Unsafe
>> >
>> > Modified:
>> > httpd/httpd/trunk/modules/http/http_filters.c
>> >
>> > Modified: httpd/httpd/trunk/modules/http/http_filters.c
>> > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/
>> http_filters.c?rev=1772418&r1=1772417&r2=1772418&view=diff
>> > 
>> ==
>> > --- httpd/httpd/trunk/modules/http/http_filters.c (original)
>> > +++ httpd/httpd/trunk/modules/http/http_filters.c Sat Dec  3 00:10:31
>> 2016
>> > @@ -667,6 +667,7 @@ static int check_header(void *arg, const
>> >  /* Simply terminate scanning on a CTL char, allowing
>> whitespace */
>> >  test = val;
>> >  do {
>> > +while (*test == ' ' || *test == '\t') test++;
>> >  test = ap_scan_vchar_obstext(test);
>> >  } while (*test == ' ' || *test == '\t');
>> >  }
>> >
>> >
>>
>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>
>

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

On Fri, Dec 2, 2016 at 6:26 PM, William A Rowe Jr 
wrote:

> FWIW, did you actually fix this on truck and convey the backport
> svn rev no?
>

I see you sort-of have... please convey the svn commit r1772418 to your
branch commit --revprop svn:log history, and I think we are all good.


> On Fri, Dec 2, 2016 at 6:25 PM, William A Rowe Jr 
> wrote:
>
>> That is code I'm less familiar with, but will give it careful scrutiny
>> tomorrow.
>>
>>
>> On Fri, Dec 2, 2016 at 6:12 PM, Eric Covener  wrote:
>>
>>> probably wiser ways to fix but I didn't want to sit on it.
>>>
>>> On Fri, Dec 2, 2016 at 7:10 PM,   wrote:
>>> > Author: covener
>>> > Date: Sat Dec  3 00:10:31 2016
>>> > New Revision: 1772418
>>> >
>>> > URL: http://svn.apache.org/viewvc?rev=1772418&view=rev
>>> > Log:
>>> > loop in checking response headers
>>> >
>>> > w/ HTTPProtocolOptions Unsafe
>>> >
>>> > Modified:
>>> > httpd/httpd/trunk/modules/http/http_filters.c
>>> >
>>> > Modified: httpd/httpd/trunk/modules/http/http_filters.c
>>> > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/
>>> http_filters.c?rev=1772418&r1=1772417&r2=1772418&view=diff
>>> > 
>>> ==
>>> > --- httpd/httpd/trunk/modules/http/http_filters.c (original)
>>> > +++ httpd/httpd/trunk/modules/http/http_filters.c Sat Dec  3 00:10:31
>>> 2016
>>> > @@ -667,6 +667,7 @@ static int check_header(void *arg, const
>>> >  /* Simply terminate scanning on a CTL char, allowing
>>> whitespace */
>>> >  test = val;
>>> >  do {
>>> > +while (*test == ' ' || *test == '\t') test++;
>>> >  test = ap_scan_vchar_obstext(test);
>>> >  } while (*test == ' ' || *test == '\t');
>>> >  }
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Eric Covener
>>> cove...@gmail.com
>>>
>>
>>
>

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[Eric Covener]

On Fri, Dec 2, 2016 at 7:28 PM, William A Rowe Jr  wrote:
> On Fri, Dec 2, 2016 at 6:26 PM, William A Rowe Jr 
> wrote:
>>
>> FWIW, did you actually fix this on truck and convey the backport
>> svn rev no?
>
>
> I see you sort-of have... please convey the svn commit r1772418 to your
> branch commit --revprop svn:log history, and I think we are all good.

It's already in the log unless I'm misunderstanding.

Re: svn commit: r1772418 - /httpd/httpd/trunk/modules/http/http_filters.c

[William A Rowe Jr]

You are correct, I read the commits out of sequence.

Thx!

On Dec 2, 2016 18:40, "Eric Covener"  wrote:

> On Fri, Dec 2, 2016 at 7:28 PM, William A Rowe Jr 
> wrote:
> > On Fri, Dec 2, 2016 at 6:26 PM, William A Rowe Jr 
> > wrote:
> >>
> >> FWIW, did you actually fix this on truck and convey the backport
> >> svn rev no?
> >
> >
> > I see you sort-of have... please convey the svn commit r1772418 to your
> > branch commit --revprop svn:log history, and I think we are all good.
>
> It's already in the log unless I'm misunderstanding.
>