-
Notifications
You must be signed in to change notification settings - Fork 553
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
FEATURE: implement body streaming for Net::HTTP #1051
base: master
Are you sure you want to change the base?
FEATURE: implement body streaming for Net::HTTP #1051
Conversation
Per bblimke#629, this adds support for body stream mocking. It is only implemented on Net::HTTP for now as this is the most surgical change we can make without impacting the entire framework.
@SamSaffron Thank you for the PR and the delightful AI conversation transcript! 😄 It's the first PR I've received with an attached AI discussion, and I appreciate the attempt! Apologies for the delay in addressing this PR. It requires some investigation into WebMock usage cases, and I haven't been able to allocate sufficient time for that yet. I find the proposed change intuitive and appreciate its alignment with the existing behavior of the Curb adapter when Transfer-Encoding is set to 'chunked' (as demonstrated in the WebMock specs: webmock/spec/acceptance/curb/curb_spec.rb Lines 101 to 111 in fc6a2ab
However, I have concerns regarding backward compatibility. A search on GitHub reveals instances where the response body is declared as an Array object (https://github.com/search?q=%22to_return%28body%3A+%5B%22+stub_request+NOT+repo%3Abblimke%2Fwebmock+NOT+%22%5D.to_json%22&type=code). While it's surprising that these examples work, it's possible that private projects also rely on this behavior. One edge case is using an empty array ( The issue likely due to WebMock's Readme not clearly defining valid cases for using an Array as the response body, yet permitting it. It's possible that for some HTTP clients, it accidentally works as if the JSON representation of an array was declared. Given the potential for breaking changes, I believe a change like this requires a new major version to avoid backward incompatibility issues. In the new major version, WebMock API should be deterministic and only accept an Array response for certain cases, rejecting it when the Array type is not supported as a response. This would help prevent confusion and inconsistent behaviour. To make the WebMock API more deterministic, we could consider introducing a new keyword, I'd love to hear your thoughts on this. |
I hear you, the I would prefer not to introduce "body_chunks" cause it is harder to learn about and instead:
That also kind of opens the door to PRs adding this support to other adapters and keeps the simple API Downside is ... got to wait for a major. |
@SamSaffron thank you for your prompt feedback. I do agree that adding :body_chunks will make the API more complicated. I'm concerned about people declaring arrays of strings as the response body, thinking they are declaring a JSON array. WebMock will accept that and no "sorry, this pattern is not supported by this adapter yet" error will be raised, but instead of a JSON array, they will receive a chunked string. |
Maybe a middle ground here is to make an "option" on webmock, then if you explicitly opt-in you get the chunked behavior and we don't need to unravel history here and can release this on a minor? Eg:
Of course curb is already a snowflake but we can make this a no-op for curb for now. |
@SamSaffron thank you! I appreciate your suggestion. After giving myself more time and spending more time considering the implications, I still have hesitations about an implicit API where the developer is expected to know that declaring While the Ideally, I believe the API should aim to be explicit and intuitive to minimize confusion. With that in mind, my current leaning is to have something like Regarding curb, I think we should deprecate declaring the I'm open to other ideas though! Let me know what you think about this approach or if you have any other suggestions. |
Per #629, this adds support for body stream mocking.
It is only implemented on Net::HTTP for now as this is the most
surgical change we can make without impacting the entire framework.