Author jaraco
Recipients eric.snow, jaraco, orsenthil, tburke
Date 2019-09-11.11:50:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1568202634.13.0.533153516387.issue36274@roundup.psfhosted.org>
In-reply-to
Content
Thank you Tim for the reasoned issue and proposed solutions.

After reviewing these proposals with @eric.snow, we've decided that this approach is dangerous in that the proposed approaches has the potential to expose users unexpectedly to non-compliant behavior, where as currently they are assured compliance. Instead, we would like to see a more explicit opt-in, such as through a separate method or through a setting on the call and/or client object.

Consider instead a solution that implements both `.putrequest` and `.putrequest_raw` or `.putrequest_allow_invalid_bytes` that sends a clear signal to the user that they're bypassing the default protections.

Or consider another approach where HTTPConnection implements an `_encode_request()` method that a subclass with a specialized need could override.

Would either of those approaches suit your use-case?
History
Date User Action Args
2019-09-11 11:50:34jaracosetrecipients: + jaraco, orsenthil, eric.snow, tburke
2019-09-11 11:50:34jaracosetmessageid: <1568202634.13.0.533153516387.issue36274@roundup.psfhosted.org>
2019-09-11 11:50:34jaracolinkissue36274 messages
2019-09-11 11:50:33jaracocreate