If point my browser to e.g.
https://openacs.org/SYSTEM/munin.tcl?t=threads, I see four lines, with currently this data
max.value 40
current.value 10
busy.value -1
nrthreads.value 49
If I do a "view source" in the browser, the newlines seem to disappear, but this is not the problem (but may help in the analysis).
The strange thing is, that for some reason, if I try to fetch this page via curl or wget, I always only get the latest key-value pair, i.e. in this case
nrthreads.value 49.
See below an example:
curl -is https://openacs.org/SYSTEM/munin.tcl?t=threads
HTTP/1.1 200 OK
Server: NaviServer/4.99.16d10
Date: Wed, 25 Oct 2017 08:23:07 GMT
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin
Set-Cookie: ad_session_id="2710947214%2c0%2c0%2c1508919787%20{669%201508920987%20B0194E1280160B1BEAEF7C5811922C542385C690}"; Expires=Fri, 01-Jan-2035 01:00:00 GMT; Path=/; Secure; Discard; HttpOnly
Content-Type: text/plain; charset=utf-8
Content-Length: 62
Connection: keep-alive
nrthreads.value 4
If I intercept the transmission using mitmproxy, the "raw response" is rendered correclty (all four lines). If I switch to hex mode, it seems as if the newlines were CR. At least, if I read this correctly:
0000000000 6d 61 78 2e 76 61 6c 75 65 20 34 30 0d 63 75 72 max.value 40.cur
0000000010 72 65 6e 74 2e 76 61 6c 75 65 20 31 30 0d 62 75 rent.value 10.bu
0000000020 73 79 2e 76 61 6c 75 65 20 2d 31 0d 6e 72 74 68 sy.value -1.nrth
0000000030 72 65 61 64 73 2e 76 61 6c 75 65 20 34 39 reads.value 49
So, what does this mean? Are the command-line clients overly picky? Or should it be 0A or 0D0A instead of 0D, to be valid? Is some misconfiguration the culprit? Any ideas? IMHO, there must be at least
something wrong on "our" side, if curl and wget arent able to display the first 3 "lines" of the response, right?
