ZNC v1.9.1 web UI (webadmin) does not support HEAD requests, only GET requests. #1067

Open
opened 2026-10-05 05:01:15 +02:00 by adam · 4 comments
Owner

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:

    - ZNC:
        href: http://znc.lan
        siteMonitor: http://znc.lan
        container: znc

Result:

Image

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.

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: ![Image](https://github.com/user-attachments/assets/0cbb2a6b-bc2c-4efe-aaff-bb0fd1f31e96) 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 -->
Author
Owner

Currently it only routes GET and POST to HTTP handler, the rest goes to IRC handler, that's why curl stalls.

Currently it only routes GET and POST to HTTP handler, the rest goes to IRC handler, that's why curl stalls. <!-- github-comment-id:2926828244 -->
Author
Owner

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.

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 -->
Author
Owner

Isn't this bug it? :)

Isn't this bug it? :) <!-- github-comment-id:2929316285 -->
Author
Owner

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.

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 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#1067