Lighttpd

%C0 represents an illegal character in UTF-8. As such, if any URL normalization is enabled (strongly recommended), presence of %C0 is treated as an error.

If some app is blindly URL-encoding binary bytes into the URL, base64 or other full encoding of the binary data is a safer solution.

As to logging of the error, in the next version of lighttpd I'll consider hiding the trace unless debug.log-request-header-on-error = "enable"

Unfortunately I don't control the apps. What's the benefit of normalizing the query string?

Is it possible to disable just the normalization of the query string?

Unfortunately I don't control the apps. What's the benefit of normalizing the query string?

It is better security practice to use a safer "explicit allow and default deny" security policy versus a less safe "explicit deny and default allow" security policy.

%C0 is illegal in UTF-8. It is not legal in the url-path. It is not legal in the query-string. It is not valid in any part of the URI. For the "explicit allow and default deny" security policy, the question is "Is there a reason to allow it?" -- not "Is there a reason to deny it?". The answer to "Is there a reason to allow it?" is no, there is not a reason to allow it. Therefore, it gets denied. "What's the benefit of normalizing the query string?" is the wrong question. The answer to the question "Should the query string be normalized?" is "yes, of course it should be normalized for an "explicit allow and default deny" security policy".

Another benefit to a clear, general security policy is being able to refuse to entertain individual questions "what about this?" "what about that?" "what about that other thing?" "what about %C0?" "what about the query string?" for each character in each part of the URI (scheme, authority, url-path, query-string, etc)