Author jaraco
Recipients jaraco
Date 2019-09-18.16:14:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1568823270.72.0.1365123921.issue38216@roundup.psfhosted.org>
In-reply-to
Content
The fix for issue30458 prevents any request line from transmitting non-ascii characters. In some cases, it's useful to transmit these illegal bytes in order to simulate a maliciously-crafted request (such as to ensure a web server responds correctly to such a request). This limitation is a regression from previous behavior that allowed transmission of such invalid requests.

For example, consider [this comment](https://github.com/cherrypy/cherrypy/issues/1781#issuecomment-507836873), where tests in CherryPy were disabled due to emergent failures against nightly builds.

Originally, I reported this issue in issue36274, but I believe this issue is distinct and has a different timeline from that issue.

In [this comment](https://bugs.python.org/issue36274#msg352711), xtreak suggests that the proper solution might be not to transmit raw invalid characters but to actually rely on URL quoting to "transmit" those bytes. While that does seem to exercise CherryPy's error detection properly, I believe it still fails to exercise the receipt and handling of raw invalid bytes, but it does provide a possible satisfactory mitigation to this issue.
History
Date User Action Args
2019-09-18 16:14:30jaracosetrecipients: + jaraco
2019-09-18 16:14:30jaracosetmessageid: <1568823270.72.0.1365123921.issue38216@roundup.psfhosted.org>
2019-09-18 16:14:30jaracolinkissue38216 messages
2019-09-18 16:14:30jaracocreate