Tested on ZNC v1.9.1, installed via Docker on Raspberry Pi 5 (arm64).
I noticed that the ZNC Web UI does not support HEAD requests, but only GET requests. This can be an issue because some monitoring tools use HEAD to determine if our service is up or down.
An example is Homepage dashboard. It monitors all services I have locally.
Notice the left monitor (Error in red) is monitoring the service at layer 7 (i.e., http). Ignore the right one as that's monitoring the docker container.
Looking at a packet capture, I can see it's using HEAD, to which znc does not respond at all.
I can get the same result and behaviour if I curl -I http://znc.lan.
the -I connects with HEAD, and curl just stalls there. Remove -I and it connects via GET request and that works as expected.
Can you please add additional code to handle a HEAD request and to just reply with the header?
Thanks.
Hi,
Tested on ZNC v1.9.1, installed via Docker on Raspberry Pi 5 (arm64).
I noticed that the ZNC Web UI does not support HEAD requests, but only GET requests. This can be an issue because some monitoring tools use HEAD to determine if our service is up or down.
An example is [Homepage](https://gethomepage.dev/) dashboard. It monitors all services I have locally.
An example config for ZNC:
```
- ZNC:
href: http://znc.lan
siteMonitor: http://znc.lan
container: znc
```
Result:

Notice the left monitor (Error in red) is monitoring the service at layer 7 (i.e., http). Ignore the right one as that's monitoring the docker container.
Looking at a packet capture, I can see it's using HEAD, to which znc does not respond at all.
```
$ tshark -r znc.pcapng -Y "tcp.stream eq 0"
1 0.000000 172.25.0.1 → 172.25.0.3 TCP 74 46564 → 6501 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=3462526257 TSecr=0 WS=128
2 0.000023 172.25.0.3 → 172.25.0.1 TCP 74 6501 → 46564 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM TSval=1571645198 TSecr=3462526257 WS=128
3 0.000032 172.25.0.1 → 172.25.0.3 TCP 66 46564 → 6501 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3462526257 TSecr=1571645198
4 0.000133 172.25.0.1 → 172.25.0.3 HTTP 315 HEAD / HTTP/1.1
5 0.000146 172.25.0.3 → 172.25.0.1 TCP 66 6501 → 46564 [ACK] Seq=1 Ack=250 Win=65024 Len=0 TSval=1571645198 TSecr=3462526257
$ tshark -r znc.pcapng -Y "frame.number == 4" -PV -O http
4 0.000133 172.25.0.1 → 172.25.0.3 HTTP 315 HEAD / HTTP/1.1
Transmission Control Protocol, Src Port: 46564, Dst Port: 6501, Seq: 1, Ack: 1, Len: 249
Hypertext Transfer Protocol
HEAD / HTTP/1.1\r\n
[Expert Info (Chat/Sequence): HEAD / HTTP/1.1\r\n]
[HEAD / HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: HEAD
Request URI: /
Request Version: HTTP/1.1
Host: znc.lan\r\n
X-Forwarded-Scheme: http\r\n
X-Forwarded-Proto: http\r\n
X-Forwarded-For: 192.168.xxx.1\r\n
X-Real-IP: 192.168.xxx.1\r\n
Connection: close\r\n
Cookie: 6501-SessionId=xxx\r\n
Cookie pair: 6501-SessionId=xxx
\r\n
[Full request URI: http://znc.lan/]
[HTTP request 1/1]
```
I can get the same result and behaviour if I `curl -I http://znc.lan`.
the -I connects with HEAD, and curl just stalls there. Remove -I and it connects via GET request and that works as expected.
Can you please add additional code to handle a HEAD request and to just reply with the header?
Thanks.
<!-- github-sync-id:3106873452 -->
Good to know. Is there a possibility to turn this into an RFE, to request the support of routing HEAD to the HTTP handler too? So that monitoring can work?
Ta.
Thanks @DarthGandalf ,
Good to know. Is there a possibility to turn this into an RFE, to request the support of routing HEAD to the HTTP handler too? So that monitoring can work?
Ta.
<!-- github-comment-id:2928541341 -->
You could (should) technically treat this as a bug since your web admin isn't RFC 9110 compliant, and does not fully conform to HTTP/1.1 or HTTP/2 specifications.
Ta.
I mean whichever is more convenient for you.
You could (should) technically treat this as a bug since your web admin isn't RFC 9110 compliant, and does not fully conform to HTTP/1.1 or HTTP/2 specifications.
Ta.
<!-- github-comment-id:2930129614 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi,
Tested on ZNC v1.9.1, installed via Docker on Raspberry Pi 5 (arm64).
I noticed that the ZNC Web UI does not support HEAD requests, but only GET requests. This can be an issue because some monitoring tools use HEAD to determine if our service is up or down.
An example is Homepage dashboard. It monitors all services I have locally.
An example config for ZNC:
Result:
Notice the left monitor (Error in red) is monitoring the service at layer 7 (i.e., http). Ignore the right one as that's monitoring the docker container.
Looking at a packet capture, I can see it's using HEAD, to which znc does not respond at all.
I can get the same result and behaviour if I
curl -I http://znc.lan.the -I connects with HEAD, and curl just stalls there. Remove -I and it connects via GET request and that works as expected.
Can you please add additional code to handle a HEAD request and to just reply with the header?
Thanks.
Currently it only routes GET and POST to HTTP handler, the rest goes to IRC handler, that's why curl stalls.
Thanks @DarthGandalf ,
Good to know. Is there a possibility to turn this into an RFE, to request the support of routing HEAD to the HTTP handler too? So that monitoring can work?
Ta.
Isn't this bug it? :)
I mean whichever is more convenient for you.
You could (should) technically treat this as a bug since your web admin isn't RFC 9110 compliant, and does not fully conform to HTTP/1.1 or HTTP/2 specifications.
Ta.