I think that we should always ensure that mod_status provides the info and insight that our users want and need, so +1 on adding fields and columns as required.
It *might* make sense to add them at the end, almost as if we were adding additional fields to a struct and wanted to maintain an API, because some users may be screen scraping, but it could also be argued that '?auto' is exactly what that is there for, so we should have the html screen look as "correct" as possible. All that being said, I'm +1 for the patch. Thx!! > On Jan 20, 2016, at 11:26 AM, Stefan Eissing <[email protected]> > wrote: > > I'd like some feedback to a small scoreboard/mod_status patch. It makes the > following changes: > - new method ap_update_child_status_from_server(ap_sb_handle_t *sbh, int > status, conn_rec *c, server_rec *s); in the API > - mod_ssl uses that to announce servers selected by TLS servername *before* > the first request comes in for vhost > - worker_score has an additional member char protoccol[16] that records > ap_get_protocol(c) when a connection is given in an update > - mod_status introduces a new columne 'Protocol' for displaying the > connection protocol used. > - vhost is no longer NULLed when a request ends > - status SERVER_READY explicitly clears client/vhost/request/protocol > > 1. I am not sure if it is sensitive to add a columns to mod_status output. It > is html after all. > 2. 16 bytes for protocol seems much, but 8 is too little for http/1.1 and > websocket would also need more... > 3. http/1.1 clear and http/1.1+tls could be worth a differentiation, but not > done for now > 4. I was considering to show some HTTP/2 information in the "Request" field, > but maybe that is only confusing? > > Feedback appreciated. > > -Stefan > > > > > <proto_status_trunk.patch>
