Out-of-specification handling of request headers on the WebGUI

[ellisdickinson46]

Issue Type: Bug
Summary: Headers sent to the WebGUI are not handled correctly causing fallback handling to apply to POST requests.

Background Info:
This server uses the HTTP/1.1 protocol which specifies that services should use case-insensitive header processing but that alternative casing-formats are allowed and should be treated as valid. HTTP/2 now specifies and enforces a lower-case only header format, any other format is considered erroneous and thus causes a compatibility issue with some clients when this protocol is in use.

Current behaviour:
Headers must be sent in a case-sensitive format to be correctly recognised and handled (e.g. Content-Type). Requests coming from client devices or servers using the all lower-case headers found in HTTP/2 will result in all requests to the server being treated as GET requests. POST requests that are made using and incorrect case type will return the template HTML for the WebGUI, and API requests are not recognised or logged in the log file, additionally no error logging is created for this issue.

Expected behaviour:
Headers should be read and processed in a case-insensitive way such that Content-Type and content-type are treated in the same way and correctly recognised be the WebGUI and its corresponding API functions irrespective of which convention or protocol the client device or server uses.

Workaround:
When using reverse proxies such as HAProxy or similar software where HTTP/2 header casing is strictly applied, translation can be applied to requests routed to iVentoy's WebGUI to translate them into the currently expected casing. In HAProxy this is achieved through options h1-case-adjust and h1-case-adjust-bogus-server. At the time of writing this seems to apply mainly to:

• Host -> host
• Content-Type -> content-type
• Content-Length -> content-length
• User-Agent -> user-agent
• Accept -> accept