How can I put an "Unsafe" into the http.server?

I am using the python http.server quite happily, but ran into a problem with one specific device.

This device, a Geiger counter, sends a url request with a finishing CR, while it should be sending a CRLF.

Apache sees this as a security risk , and rejects such requests with “400 Bad Request” and logs it as “malformed request line” (…, scroll to “important: Apache HTTP Request Parsing Whitespace Defects (CVE-2016-8743)”).

For Apache one can work around this by entering into apache2.conf :

HttpProtocolOptions Unsafe

(The default being HttpProtocolOptions Strict ). My local Apache server is now working with that dirty device.

I suppose the Python server is of the same opinion as Apache, and rejects these requests for the same reason. Is there anything I can do to my Python server to also make it accept CR in a request where a CRLF should be?

Putting “Unsafe” into the config of a public web server is probably a good example of what NOT to do, but in my case the counter would be run in a local LAN, and security is not of any concern.

The Geiger counter has closed source firmware, so is not accessible to me.

Upon further investigation: the culprit is actually an ESP8266 chip, providing the WiFi capabilities to the Geiger counter, which is running ESP-AT code.

When sending an AT+GMR command to it, it responds with

AT+GMR\r\r\nAT version: 1 2016 20:04:45)\r\nSDK version:\r\nAi-Thinker Technology Co. Ltd.\r\nDec 2 2016 14:21:16\r\nOK\r\nWIFI DISCONNECT\r\nWIFI CONNECTED\r\nWIFI GOT IP\r\n\n

So the AT version in use is from 2016, so is “pretty old” by internet standards. (The Apache bug fix was released in Dec 2016)

Does anyone have experience with the interaction of http.server with ESP-AT commands? Does it work with newer versions of ESP-AT?

Edit: the link to the Apache bug description given above is broken. Here the proper one:

The source code of http.server is fairly simple and has just a few security features.
You can check the parsing here and compare it with the CVE: cpython/ at 65268ab849173e9849b7fc94c3d73900b5410444 · python/cpython · GitHub

@scenox Thanks for the pointer! Yes, the line #284 seems to be the one, and would be really easy to adapt.

Unfortunately, I have now discovered that the Geiger counter seems to be hard-coded for its settings, and does not allow the changes I would have needed to make :-//