update 2024.02.1 -> 2026.01.3
most notably adding support for HackRF Pro, that I tested with
with a number of consumers, as well as got reports for HackRF One.
Maintainer timeout
relayd: strip Content-Length for chunked messages
RFC 9112 section 6.1 requires an intermediary that forwards a message
carrying Transfer-Encoding to remove any received Content-Length first.
relayd already parses the body as chunked in this case, but previously
left Content-Length in the header tree, so the backend could receive
both framing fields and choose a different message boundary.
When chunked framing is selected, remove Content-Length before header
emission; this preserves relayd's chunked body handling while avoiding
CL.TE ambiguity downstream.
Reproted by: Stuart Thomas
OK: rsaodwski@
httpd: reject CL.TE request framing
RFC 9112 sections 6.1 and 6.3 identify a request containing both
Transfer-Encoding and Content-Length as ambiguous request smuggling
input. httpd is the origin server, not an intermediary, so it should not
rewrite the message and continue processing it.
Reject chunked requests that also carry Content-Length before method
specific body handling or FastCGI parameter generation; this avoids
exposing inconsistent framing metadata to applications.
Reproted by: Stuart Thomas
OK: rsaodwski@
relayd: reject obs-fold to prevent parser differentials (RFC 9112 5.2)
Replace silent kv_extend normalisation with an unconditional reject.
RFC 9112 5.2 permits rejection; it is safer than SP replacement
for a forwarding proxy and handles both request and response direction.
kv_extend is therefore no longer required.
Reported by Stuart Thomas, OK kirill@
httpd: reject obs-fold with 400 (RFC 9112 5.2)
Replace silent kv_extend normalisation with an unconditional 400.
RFC 9112 5.2 explicitly permits rejection; it is the safer choice
over SP replacement, which hides parser ambiguity downstream.
Reported by Stuart Thomas, OK kirill@
