Re: JSON for mod_status

[William A Rowe Jr]

You are looking at one fold of monitoring data. See, for example,
mod_bmx_vhost which further extends many beans by hostname.

The response generator and framework lives in mod_bmx itself.

On Nov 30, 2016 14:35, "Jim Jagielski"  wrote:

One thing that I can't understand from an initial look
is how the whole hook thing is. In mod_status, we have a hook
that is run in mod_status and other modules use to supplement
the mod_status output.

With mod_bmx it looks like instead whatever "chunk" of data
you want to make available, you put into a bean, but mod_bmx_status
uses a local bean with no provision to print out other
beans as well.

How does one "extend" the info printed by mod_bmx_status
via other beans added and populated by other modules?

RE: JSON for mod_status

[Houser, Rick]

Personally, I'd rather have XML, but it may make sense to support multiple 
machine readable formats down the line.  As such, using a new parameter for 
every possibility gets messy.  If this gets implemented as a get parameter, how 
about making one parameter with multiple potential values down the line?  It's 
not like they would all have to be implemented up-front.

?type=json
?type=xml
?type=js
?type=csv
Etc.

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.


Rick Houser
Web Administration

> -Original Message-
> From: Jordan Gigov [mailto:colad...@gmail.com]
> Sent: Wednesday, November 30, 2016 13:20
> To: dev@httpd.apache.org
> Subject: Re: JSON for mod_status
> 
> I think a better approach than "?json=true" would be to to respect the
> "Accept" header values of "application/json" and "text/json" if they
> have the higher priority.
> XML output should also be an option, if it will indeed serve as an API
> end-point.
> 
> On 30 November 2016 at 20:08, Luca Toscano 
> wrote:
> >
> >
> > 2016-11-30 19:03 GMT+01:00 Daniel Gruno :
> >>
> >> On 11/30/2016 06:54 PM, Jim Jagielski wrote:
> >> > I'm thinking about adding JSON support to mod_status...
> >> > the "plain" version output really stinks and lacks parity
> >> > w/ the info we provide via HTML, and it would be nice
> >> > to produce a really easily parseable format.
> >> >
> >> > Thoughts...?
> >
> >
> > +1, this will simplify a lot things like metrics collectors polling httpd
> > regularly (that don't need a nice html format).
> >
> >> +1, a ?json=true or some such to the query would be helpful.
> >> so you could do
> >> /server-status?json=true
> >> or
> >> /server-status?auto&json=true
> >>
> >
> > +1, I like the idea!
> >
> > Thanks!
> >
> > Luca
> >

Re: JSON for mod_status

[Jim Jagielski]

One thing that I can't understand from an initial look
is how the whole hook thing is. In mod_status, we have a hook
that is run in mod_status and other modules use to supplement
the mod_status output.

With mod_bmx it looks like instead whatever "chunk" of data
you want to make available, you put into a bean, but mod_bmx_status
uses a local bean with no provision to print out other
beans as well.

How does one "extend" the info printed by mod_bmx_status
via other beans added and populated by other modules?

Sub-modules viability (was: [Vote] Considering mod_bmx for adoption by HTTP Server Project)

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 2:05 PM, Jim Jagielski  wrote:

>
> Module sub-modules NEVER get the love and attention they need
> and warrant
>

It would be interesting to see this applied to fcgid on a fast-track.
I don't know that ftp warrants it this moment. I don't know why arm4
is still one of our repositories with never-a-release.

I made the direct-to-trunk-backport-2.4 proposal based on the efforts
of Stefan who has continued to maintain a buildable external third
party module of mod_h2, while keeping it in-sync with httpd 2.4.

Maybe it is the better model. Older httpd flavors don't get the patch
attention and backport considerations they need. Independently,
Stefan can maintain a viable third party plug-in module for older flavors
of httpd, but it can move forward with httpd core. No waiting on any
backport votes, it simply happens when Stefan has cycles to do it.

Contrawise, mod_h2 plugable add-on could have become a modules
sub-project and available from the ASF. Either way, there is some level
of synchronization required. Since Stefan is doing that all, it's truly
his choice of what is simplest.

Likewise, I'm happy to ensure mod_bmx on github continues to be
a viable plug-in to httpd-2.2 or 2.4, and carry back the AL commits
to the trunk/2.4 branch efforts at httpd.

Having maintained a few sub-modules with mixed success, I'd be
happy to see us retire the model, it simply doesn't work any better
than landing on the perpetual 2.4.x release side-track. It seems like
the entire effort has slipped the rail, but more on that in a few weeks
when 2.4.24 is put to bed. In the meantime, there seems to already
be consensus to shift mod_fcgid as well to trunk/.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 2:10 PM, Jim Jagielski  wrote:

> One final note:
>
> The reason I brought all this up is that right now, using mod_status
> for actual automated status checking is downright painful. At
> ApacheCon, due to, I guess, me adding the mod_status hooks to
> the redis and memcache socache providers, people came up to
> me and asked when, if ever, we would support JSON in mod_status.
>

++1 :)

S
>
> What I was hoping for was an implementation that could easily,
> and in some reasonable timeframe, be made available to our
> 2.4.x community. I don't want something that just ends up
> in trunk, to sit and languish until the day when we eventually
> decide on releasing 2.6/3.0.
>

Since it's written and is working just fine (and is part of the RHEL
distribution) - let's bring bmx in, then think about how to refactor
the bean data and status hooks to converge them in 2.next/3.0.
Or we can play NIH. (Especially absurd since an httpd committer
wrote the whole first implementation.)

Re: JSON for mod_status

[Jim Jagielski]

One final note:

The reason I brought all this up is that right now, using mod_status
for actual automated status checking is downright painful. At
ApacheCon, due to, I guess, me adding the mod_status hooks to
the redis and memcache socache providers, people came up to
me and asked when, if ever, we would support JSON in mod_status.

S

What I was hoping for was an implementation that could easily,
and in some reasonable timeframe, be made available to our
2.4.x community. I don't want something that just ends up
in trunk, to sit and languish until the day when we eventually
decide on releasing 2.6/3.0.

Re: [Vote] Considering mod_bmx for adoption by HTTP Server Project

[Jim Jagielski]

> On Nov 30, 2016, at 2:59 PM, William A Rowe Jr  wrote:
> 
> 
> [X] Accept mod_bmx into the httpd trunk (for possible backport consideration)
> 

Module sub-modules NEVER get the love and attention they need
and warrant.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 1:58 PM, Jim Jagielski  wrote:

> I'm not pushing back on mod_bmx at all... I just think
> that there is a better understanding here about "mod_status
> producing JSON" than what the changeover to mod_bmx would
> be.
>
> What I would push back on would be having 2 implementations,
> since that's just weird :) But if the BMX data format is
> "better" then we should use that.
>
> As Nick said, what is key is that we should produce this
> internal data in a known and easily parseable exchange
> format, one that we can then directly send as a response
> as well as one which we can, via a provider-like interface,
> xlate to HTML and other "common" formats. Right now, I
> think "plain", "json" and "html" are the only ones we
> should worry about.
>

So to be clear, it is easy to flip mod_status's core data to any
one of dozens of formats without any further debate.

It is not so easy to carry along the third party hooked status
representations of *their* data, not being able to predict how
httpd 2.4.x will keep changing behavior during it's 'maintenance'
lifespan, not knowing how they presented  lists or tables
and how they aught to be mapped to json tokens.

Contra-wise, turning everything into json-always with 2.next
or 3.0 isn't a solution either, since there's no way for mod_status
to predict the best representation of the json output from any
hooked third party modules.

So the best solution, IMO, is to map as beans all of the data
to be represented as raw json (and other raw formats), which can
be filtered for the 'interesting' data that downstream monitoring
clients want to consume, and leave the existing status hook
for third party modules to map their data into presentation html
(or xml, if we want to go that way.)

[Vote] Considering mod_bmx for adoption by HTTP Server Project

[William A Rowe Jr]

I'm pleased to conversations with the principal folks that Hyperic/VMW and
Pivotal are interested in passing along the mod_bmx codebase to the httpd
project, if we will have it.

https://github.com/hyperic/mod_bmx

Scoped by the Hyperic team to represent mod_status info in a flexible and
extensible bean-registry of items, which are reported over http in a
json-parsable format, and replaced the need for mod_snmp, it also extends
status insight into specific vhost activity, although this measurement
requires locking which may be too painful for some admins.

Written initially by out own Aaron Bannert contracting to Hyperic, it has
been maintained by Ryan Morgan and myself, along with other odd patches,
including recent fixes by Maxime Beck and folks on jfclere's team. Since we
are already spanning vendors, httpd seems like the perfect commons space to
further build on this work.

I have a champion to shepard code grant paperwork through
VMW/Hyperic/Pivotal signatories, if we choose to accepting the donation.

There seem to be two paths for us to accept this donation, so I'll put this
out as a three choice answer;

[  ] Accept mod_bmx into the httpd project as a module sub-project

[  ] Accept mod_bmx into the httpd trunk (for possible backport
consideration)

[  ] Decline mod_bmx donation


Votes? Please feel free to switch the Subject: line to launch into
side-discussions about the source code, all inquiries are welcome.

Re: JSON for mod_status

[Jim Jagielski]

I'm not pushing back on mod_bmx at all... I just think
that there is a better understanding here about "mod_status
producing JSON" than what the changeover to mod_bmx would
be.

What I would push back on would be having 2 implementations,
since that's just weird :) But if the BMX data format is
"better" then we should use that.

As Nick said, what is key is that we should produce this
internal data in a known and easily parseable exchange
format, one that we can then directly send as a response
as well as one which we can, via a provider-like interface,
xlate to HTML and other "common" formats. Right now, I
think "plain", "json" and "html" are the only ones we
should worry about.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 1:41 PM, Jim Jagielski  wrote:

> > On Nov 30, 2016, at 2:31 PM, William A Rowe Jr 
> wrote:
> >
> > On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski  wrote:
> >
> > > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr 
> wrote:
> > >
> > >
> > > There's no way to anticipate the "right way" to map json
> > > tables to presentation-level results.
> >
> > ???
> >
> > Certainly that is the job of the xlate provider that
> > would be used, wouldn't it. Or are you suggesting that
> > JSON itself isn't suitable as a data format in this case?
> >
> > I'm asking how one would maintain the xslt for the half dozen
> > json data providers of mod_status extensions within the stock
> > distro, PLUS any mod_status extension providers in the third
> > party world of modules?
> >
>
> U the data providers that hook into mod_status simply
> push JSON. Same w/ any other extension providers. That is,
> ALL mod_status does is provide JSON data; mod_status_html takes
> that JSON format and xlates it to HTML; mod_status_plain takes
> it and xlates it to simple text.
>
> Where does JSON fail and bean succeed?
>
> Other than being something that I brought up, I'm not sure
> I understand your resistance, or why/how BMX is "better"
> than JSON.


BMX is entireliy JSON. I have no argument with your suggestion, which
is why I'm bringing it up (you are the only one on the private list to have
pushed back against adopting mod_bmx, why so I'm really not clear.)

As you can see in the sources, mod_bmx_status is interrogating the
scoreboard, not mod_status, for the underlying data.

Beans provide a completely extensible way to map additional data for
mod_bmx to present. What I'm questioning is whether a transliteration
of unknown-future data can ever succeed, or whether third party modules
won't need both a presentation-layer and json/bean-layer to represent
their data in user and machine usable formats.

I'm not familiar with a good interface for json -> html, pointers would be
appreciated. I'm fairly familiar with xml -> json + xml -> html using xslt.
That's presuming you know the entire plane of data to represent.

Re: JSON for mod_status

[Jim Jagielski]

So the only concern is that you prefer XML over JSON??

Re: JSON for mod_status

[Jim Jagielski]

> On Nov 30, 2016, at 2:31 PM, William A Rowe Jr  wrote:
> 
> On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski  wrote:
> 
> > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr  wrote:
> >
> >
> > There's no way to anticipate the "right way" to map json
> > tables to presentation-level results.
> 
> ???
> 
> Certainly that is the job of the xlate provider that
> would be used, wouldn't it. Or are you suggesting that
> JSON itself isn't suitable as a data format in this case?
> 
> I'm asking how one would maintain the xslt for the half dozen
> json data providers of mod_status extensions within the stock 
> distro, PLUS any mod_status extension providers in the third
> party world of modules?
> 

U the data providers that hook into mod_status simply
push JSON. Same w/ any other extension providers. That is,
ALL mod_status does is provide JSON data; mod_status_html takes
that JSON format and xlates it to HTML; mod_status_plain takes
it and xlates it to simple text.

Where does JSON fail and bean succeed?

Other than being something that I brought up, I'm not sure
I understand your resistance, or why/how BMX is "better"
than JSON.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski  wrote:

>
> > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr 
> wrote:
> >
> >
> > There's no way to anticipate the "right way" to map json
> > tables to presentation-level results.
>
> ???
>
> Certainly that is the job of the xlate provider that
> would be used, wouldn't it. Or are you suggesting that
> JSON itself isn't suitable as a data format in this case?
>

If we have well-formed xml today out of mod_status, it's pretty
straightforward to write the json transformation you want as an
xslt through filtering, provided you plug in a libxslt transform.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 1:27 PM, Jim Jagielski  wrote:

>
> > On Nov 30, 2016, at 1:56 PM, William A Rowe Jr 
> wrote:
> >
> >
> > There's no way to anticipate the "right way" to map json
> > tables to presentation-level results.
>
> ???
>
> Certainly that is the job of the xlate provider that
> would be used, wouldn't it. Or are you suggesting that
> JSON itself isn't suitable as a data format in this case?
>

I'm asking how one would maintain the xslt for the half dozen
json data providers of mod_status extensions within the stock
distro, PLUS any mod_status extension providers in the third
party world of modules?

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 1:22 PM, Jim Jagielski  wrote:

> Any online examples of it running? It's been a SUPER long
> time since I looked at it. And I can't recall what the bean
> framework is or does...


As with /server-status - not advised unless you EDONTCARE about
host inspection.

The bean framework allows you to expand the nodes known to the
bmx data store, with new arbitrary fields and values.

This 380-line module maps all of the conventional mod_status data
into the status bean data for reporting through mod_bmx...

https://github.com/hyperic/mod_bmx/blob/master/modules/bmx/mod_bmx_status.c

Other modules can provide similar beans that can be globbed from
the /bmx-status generated page based on pattern matching. There
are few predefined constraints on the labeling.

Re: JSON for mod_status

[Jim Jagielski]

> On Nov 30, 2016, at 1:56 PM, William A Rowe Jr  wrote:
> 
> 
> There's no way to anticipate the "right way" to map json
> tables to presentation-level results.

???

Certainly that is the job of the xlate provider that
would be used, wouldn't it. Or are you suggesting that
JSON itself isn't suitable as a data format in this case?

Re: JSON for mod_status

[Kurt Newman]

Sounds like a great module.

Couple questions.
1. This seems to provide a lot more information than mod_status.  Is this 
correct?
2. If this provides more information than mod_status, what are the implications 
of running this on a shared server where local users can query Apache directly 
via localhost, and you may not want them to?
3. What happens with the permissions of the backend DBM file when each process 
is running as a different user (e.g. via mod_ruid2 or mpm_itk)?

> On Nov 30, 2016, at 12:50 PM, William A Rowe Jr  wrote:
> 
> On Wed, Nov 30, 2016 at 11:54 AM, Jim Jagielski  > wrote:
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?
> 
> It's right here...
> 
> https://github.com/hyperic/mod_bmx/blob/master/README-BMX.txt 
> 
> 
> I'd brought this to the PMC's attention to see if there were sufficient
> maintainers and interested parties. In short, the original author was
> our own Bannert.
> 
> In short, Pivotal is offering this to the HTTPD project under AL 2.0
> (as it's already licensed).
> 
> Right now, jfclere and I are the only two really looking at the code,
> although it has many commercial adopters (the preferred httpd
> introspection agent of the Hyperic monitoring software).
> 
> What bannert coded was more than converting status -> json.
> He build a bean framework that is extensible to any other httpd
> module. It seems like that bean framework might even be a
> candidate to move into the httpd core with 2.next?
> 
> As far as extentions, his most useful was the mod_bmx_vhost
> plug in. Taking it to the next step, that module should be able
> to shoot out a nice presentation table for mod_status users,
> while folks inspecting the bmx json bean interface already get
> these vhost-specific breakdowns.
> 
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: JSON for mod_status

[Jim Jagielski]

Any online examples of it running? It's been a SUPER long
time since I looked at it. And I can't recall what the bean
framework is or does...

> On Nov 30, 2016, at 1:50 PM, William A Rowe Jr  wrote:
> 
> On Wed, Nov 30, 2016 at 11:54 AM, Jim Jagielski  wrote:
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?
> 
> It's right here...
> 
> https://github.com/hyperic/mod_bmx/blob/master/README-BMX.txt
> 
> I'd brought this to the PMC's attention to see if there were sufficient
> maintainers and interested parties. In short, the original author was
> our own Bannert.
> 
> In short, Pivotal is offering this to the HTTPD project under AL 2.0
> (as it's already licensed).
> 
> Right now, jfclere and I are the only two really looking at the code,
> although it has many commercial adopters (the preferred httpd
> introspection agent of the Hyperic monitoring software).
> 
> What bannert coded was more than converting status -> json.
> He build a bean framework that is extensible to any other httpd
> module. It seems like that bean framework might even be a
> candidate to move into the httpd core with 2.next?
> 
> As far as extentions, his most useful was the mod_bmx_vhost
> plug in. Taking it to the next step, that module should be able
> to shoot out a nice presentation table for mod_status users,
> while folks inspecting the bmx json bean interface already get
> these vhost-specific breakdowns.
> 
> 
> 
> 

Re: JSON for mod_status

[Jim Jagielski]

Yeah, this is the real solution... mod_status should produce
just JSON and there are addable filters (or providers) that
take that canonical output and xlate it to whatever format
the end-user wants.

> On Nov 30, 2016, at 1:38 PM, Nick Kew  wrote:
> 
> On Wed, 2016-11-30 at 12:54 -0500, Jim Jagielski wrote:
>> I'm thinking about adding JSON support to mod_status...
>> the "plain" version output really stinks and lacks parity
>> w/ the info we provide via HTML, and it would be nice
>> to produce a really easily parseable format.
>> 
>> Thoughts...?
> 
> Ideally that should be the job of an output filter.
> If mod_status were to generate a single standard-ish
> format, like JSON or XML, a general-purpose filter
> could generate other formats.
> 
> -- 
> Nick Kew
> 

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 12:38 PM, Nick Kew  wrote:

> On Wed, 2016-11-30 at 12:54 -0500, Jim Jagielski wrote:
> > I'm thinking about adding JSON support to mod_status...
> > the "plain" version output really stinks and lacks parity
> > w/ the info we provide via HTML, and it would be nice
> > to produce a really easily parseable format.
> >
> > Thoughts...?
>
> Ideally that should be the job of an output filter.
> If mod_status were to generate a single standard-ish
> format, like JSON or XML, a general-purpose filter
> could generate other formats.
>

The underlying flaw is our extensible status page output.

There's no way to anticipate the "right way" to map json
tables to presentation-level results. And modules may
express multiple tables. See the ssl session cache for
one good example, a simply key-value table of some of
the current metrics, and a longer table for data.

So there either needs to be an extensible data engine as
Aaron created, with each status module choosing how to
represent it's component data, or mod_status needs two
custom hooks, one chain for presentation data and one
chain for json data. Existing mod_status extentions in
modules only register the presentation hook, so they
would not be invoked on a json query.

mod_bmx avoids this quandary by placing a different
generator for json queries complete with filtering.

Based on the interest expressed on this thread, I'm
happy to put mod_bmx up for a vote tomorrow after
letting this thread run for a bit.

Re: JSON for mod_status

[William A Rowe Jr]

On Wed, Nov 30, 2016 at 11:54 AM, Jim Jagielski  wrote:

> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
>
> Thoughts...?
>

It's right here...

https://github.com/hyperic/mod_bmx/blob/master/README-BMX.txt

I'd brought this to the PMC's attention to see if there were sufficient
maintainers and interested parties. In short, the original author was
our own Bannert.

In short, Pivotal is offering this to the HTTPD project under AL 2.0
(as it's already licensed).

Right now, jfclere and I are the only two really looking at the code,
although it has many commercial adopters (the preferred httpd
introspection agent of the Hyperic monitoring software).

What bannert coded was more than converting status -> json.
He build a bean framework that is extensible to any other httpd
module. It seems like that bean framework might even be a
candidate to move into the httpd core with 2.next?

As far as extentions, his most useful was the mod_bmx_vhost
plug in. Taking it to the next step, that module should be able
to shoot out a nice presentation table for mod_status users,
while folks inspecting the bmx json bean interface already get
these vhost-specific breakdowns.

Re: JSON for mod_status

[Nick Kew]

On Wed, 2016-11-30 at 12:54 -0500, Jim Jagielski wrote:
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?

Ideally that should be the job of an output filter.
If mod_status were to generate a single standard-ish
format, like JSON or XML, a general-purpose filter
could generate other formats.

-- 
Nick Kew

Re: JSON for mod_status

[Kurt Newman]

+1

> On Nov 30, 2016, at 11:54 AM, Jim Jagielski  wrote:
> 
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?



smime.p7s
Description: S/MIME cryptographic signature

Re: JSON for mod_status

[Jacob Perkins]

Howdy,

I saw your tweet on that this morning, and I think it would be a useful 
addition to have mod_status output in a machine readable format for easy 
interpolation and munging.

+1

—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

> On Nov 30, 2016, at 11:54 AM, Jim Jagielski  wrote:
> 
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?

Re: JSON for mod_status

[Daniel Gruno]

On 11/30/2016 07:20 PM, Jordan Gigov wrote:
> I think a better approach than "?json=true" would be to to respect the
> "Accept" header values of "application/json" and "text/json" if they
> have the higher priority.

Or both? Practically speaking, showing JSON based on a query arg is
vastly easier for laymen to implement in their applications than setting
accept headers, AND you can query and get JSON in your browser also.

> XML output should also be an option, if it will indeed serve as an API
> end-point.

Meh, I honestly have not used XML in a decade, so I'm +/-0 on that one.
If someone wants to do it, fine, but .. :p

> 
> On 30 November 2016 at 20:08, Luca Toscano  wrote:
>>
>>
>> 2016-11-30 19:03 GMT+01:00 Daniel Gruno :
>>>
>>> On 11/30/2016 06:54 PM, Jim Jagielski wrote:
 I'm thinking about adding JSON support to mod_status...
 the "plain" version output really stinks and lacks parity
 w/ the info we provide via HTML, and it would be nice
 to produce a really easily parseable format.

 Thoughts...?
>>
>>
>> +1, this will simplify a lot things like metrics collectors polling httpd
>> regularly (that don't need a nice html format).
>>
>>> +1, a ?json=true or some such to the query would be helpful.
>>> so you could do
>>> /server-status?json=true
>>> or
>>> /server-status?auto&json=true
>>>
>>
>> +1, I like the idea!
>>
>> Thanks!
>>
>> Luca
>>

Re: JSON for mod_status

[Jordan Gigov]

I think a better approach than "?json=true" would be to to respect the
"Accept" header values of "application/json" and "text/json" if they
have the higher priority.
XML output should also be an option, if it will indeed serve as an API
end-point.

On 30 November 2016 at 20:08, Luca Toscano  wrote:
>
>
> 2016-11-30 19:03 GMT+01:00 Daniel Gruno :
>>
>> On 11/30/2016 06:54 PM, Jim Jagielski wrote:
>> > I'm thinking about adding JSON support to mod_status...
>> > the "plain" version output really stinks and lacks parity
>> > w/ the info we provide via HTML, and it would be nice
>> > to produce a really easily parseable format.
>> >
>> > Thoughts...?
>
>
> +1, this will simplify a lot things like metrics collectors polling httpd
> regularly (that don't need a nice html format).
>
>> +1, a ?json=true or some such to the query would be helpful.
>> so you could do
>> /server-status?json=true
>> or
>> /server-status?auto&json=true
>>
>
> +1, I like the idea!
>
> Thanks!
>
> Luca
>

Re: JSON for mod_status

[Luca Toscano]

2016-11-30 19:03 GMT+01:00 Daniel Gruno :

> On 11/30/2016 06:54 PM, Jim Jagielski wrote:
> > I'm thinking about adding JSON support to mod_status...
> > the "plain" version output really stinks and lacks parity
> > w/ the info we provide via HTML, and it would be nice
> > to produce a really easily parseable format.
> >
> > Thoughts...?
>

+1, this will simplify a lot things like metrics collectors polling httpd
regularly (that don't need a nice html format).

+1, a ?json=true or some such to the query would be helpful.
> so you could do
> /server-status?json=true
> or
> /server-status?auto&json=true
>
>
+1, I like the idea!

Thanks!

Luca

Re: JSON for mod_status

[Daniel Gruno]

On 11/30/2016 06:54 PM, Jim Jagielski wrote:
> I'm thinking about adding JSON support to mod_status...
> the "plain" version output really stinks and lacks parity
> w/ the info we provide via HTML, and it would be nice
> to produce a really easily parseable format.
> 
> Thoughts...?
> 
+1, a ?json=true or some such to the query would be helpful.
so you could do
/server-status?json=true
or
/server-status?auto&json=true

etc.

JSON for mod_status

[Jim Jagielski]

I'm thinking about adding JSON support to mod_status...
the "plain" version output really stinks and lacks parity
w/ the info we provide via HTML, and it would be nice
to produce a really easily parseable format.

Thoughts...?

Content-Length header for HTTP 204 and 1xx status codes

[Luca Toscano]

Hi everybody,

while working on https://bz.apache.org/bugzilla/show_bug.cgi?id=51350 a
user asked why httpd send the "Content-Length: 0" header for HTTP 204
responses given the following statement in the RFC:

https://tools.ietf.org/html/rfc7230#page-30
"A server MUST NOT send a Content-Length header field in any response with
a status code of 1xx (Informational) or 204 (No Content)."

I tried with a simple PHP script returning an HTTP 204 header (via
mod_proxy_fcgi) and indeed I can see the Content-Length: 0. After a bit of
digging it seems that ap_content_length_filter in protocol.c adds the
header when it evaluates:

if (!(r->header_only
  && !r->bytes_sent
  && (r->sent_bodyct
  || conf->http_cl_head_zero != AP_HTTP_CL_HEAD_ZERO_ENABLE
  || apr_table_get(r->headers_out, "Content-Length" {
ap_set_content_length(r, r->bytes_sent);
}

An idea to fix the issue after a bit of chat on IRC could be the following
snippet, even if it might no be the right move. Since I am not expert
enough to attempt any code change to http_filters.c or protocol.c, I'll
wait for some feedback about how to proceed (that might also be "don't do
anything, it is fine in this way" :)

Thanks!

Luca

Index: modules/http/http_filters.c
===
--- modules/http/http_filters.c (revision 1772052)
+++ modules/http/http_filters.c (working copy)
@@ -1296,6 +1296,10 @@
 apr_table_unset(r->headers_out, "Content-Length");
 }

+if ((r->status == HTTP_NO_CONTENT || ap_is_HTTP_INFO(r->status)) &&
!r->bytes_sent) {
+apr_table_unset(r->headers_out, "Content-Length");
+}
+
 ctype = ap_make_content_type(r, r->content_type);
 if (ctype) {
 apr_table_setn(r->headers_out, "Content-Type", ctype);