-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds a Realistic WSGI Server for Testing #5915
base: main
Are you sure you want to change the base?
Conversation
…f the tests to verify that chunked encoding works correctly.
…on refused" error in MacOS. Maybe the server simply isn't ready yet and it's a flake.
…ccepting connections before returning.
…onnection timeouts. Let's try adding one.
Pull to make sure we get the 10-minute request timeout.
…hen waiting: Instead, we close any socket that fails to connect and try again with a fresh one.
…ependency. Re-add it.
Finally got the test server to verify that it is actually ready to accept connections in a robust way! Sorry about holding the test queue up for so long. |
This PR has been sitting here for a while and I'm wondering if there's still any interest from the maintainers with regard to improving your tests. If I can get some feedback that you would prefer to test against a realistic WSGI server instead of the existing simple socket and that you'd accept the PR, I'll refactor all of your tests to use the If there is no interest, I'll close this PR. |
There's interest in adding a WSGI server not in replacing it entirely. There are tests that a socket server is still incredibly valuable for and tests that a higher level server would be better suited to. |
@sigmavirus24 Sure, I buy that. In the interest of closing this PR and making things better, I need clarification on how you want to proceed:
|
I'd still like to see requests move towards more realistic testing against an actual implementation of PEP 3333. If any specific guidance can be provided on what the expectations are in order to merge this PR, I will make the necessary modifications or refactor additional tests. |
Hello! This pull request is very old, but I still feel that adding realistic tests against a reference implementation of PEP 3333 would be worthwhile. If any guidance can be provided as to what the maintainers' expectations are in order to merge this change, then I will be happy to conform to those expectations and also to refactor any desired subset of the existing tests. |
Sending of chunked-encoded data is not currently tested to be correct anywhere in requests' tests, and is called out as a needed improvement in #5906. This is a hurdle to accepting #5664, a change which would both simplify requests' code and consistently use urllib3 for retrying errors.
The existing test server is a simple socket that can send and receive data and is not aware of HTTP protocols. Therefore, using it to verify correct sending of chunked-encoded data, for instance, would ultimately become a change-detector test.
This change seeks to remedy that while also taking a step towards both simplifying and strengthening requests' tests.
We strengthen requests' tests by introducing the popular Werkzeug library as an explicit test dependency (Flask, which uses Werkzeug, is already a test dependency). By doing so, we leverage their authority as an implementer of PEP 3333 to validate our own implementation of chunked encoding. This implicitly future-proofs against any hypothetical breaking changes to the standard by testing against Werkzeug's trusted implementation.
We also simplify requests' tests, since the implementation of the test WerkzeugServer here is substantially more concise than the current test server. If this change is accepted, in another pull request I will refactor all of requests' tests to use the WerkzeugServer rather than the current test server.