Hi,

Some clients refuse to send payloads that don't match the Content-Type. That is, trying to send %BOLD hw or \x02 hw (unescaped) would be disallowed for Content-Type: application/x-www-form-urlencoded unless first encoded. As many likely know (and perhaps prefer), curl's -d|--data option sends this very header despite not doing any encoding. And irccat, it seems, was designed to expect this combination, so it doesn't perform any decoding.

However, it might be nice to allow problematic clients to specify a config option (I've called it http.listeners.generic.strict), to get the following behavior:

Mismatch

$ echo "%BOLDhw" | curl -d @- http://localhost/send
400 Bad Request

urlencoded

$ echo "%BOLDhw" | curl --data-urlencode  @- http://localhost/send
200 OK

urlencoded non-printable char

$ printf "\x02hw" | curl --data-urlencode  @- http://localhost/send
200 OK

octetstream

$ echo "%BOLDhw" | curl --data-binary @- \
    -H 'Content-Type: application/octet-stream' http://localhost/send
200 OK

multipart quoted-printable

$ echo '%BOLDhw' | curl -F 'foo=@-;encoder=quoted-printable' \
    http://localhost/send
200 OK

multipart 8bit

$ echo '%BOLDhw' | curl -F 'foo=@-;encoder=8bit' http://localhost/send
200 OK

multipart base64

$ echo '%BOLDhw' | curl -F 'foo=@-;encoder=base64' http://localhost/send
200 OK

IOW, when "strict" mode is active, popular encodings will work as expected.
Please see associated tests. Thanks.