Optionally decode generic HTTP payloads #26
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 forContent-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
urlencoded
urlencoded non-printable char
octetstream
multipart quoted-printable
multipart 8bit
multipart base64
IOW, when "strict" mode is active, popular encodings will work as expected.
Please see associated tests. Thanks.