Message351834
| 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:34 | jaraco | set | recipients:
+ jaraco, orsenthil, eric.snow, tburke |
| 2019年09月11日 11:50:34 | jaraco | set | messageid: <1568202634.13.0.533153516387.issue36274@roundup.psfhosted.org> |
| 2019年09月11日 11:50:34 | jaraco | link | issue36274 messages |
| 2019年09月11日 11:50:33 | jaraco | create |
|