aiohttp
aiohttp copied to clipboard
feat: enable reuse of FromData instance
I have been facing a situation that an API I was requesting would have some retryable error especially with form-data requests. While with reusing the FormData instance in my request, the RuntimeError was raised. In this case, I was confused that why the FormData instance would raise error upon re-gen.
With looking into the source code of aiohttp, I cannot discover any possible errors that may occurs with the reuse of FormData instance, especially the MultipartWriter seems to be designed with the ability to write() for more than once. As a result, I tried the change in this pr in my own code to test and proved that the resulting form-data to be send is correctly outputted.
To work more, with the fact that MultipartWriter seems to be designed for more than one time usage, the FormData may also accept further adding fields into the writer after already generated form data for a certain number of times. With this, it might be more flexible for we to deal with form-data request.
What do these changes do?
- do not raise RuntimeError with the reuse of FormData instance but returning self._writer
- after already generated form data for a certain number of times, allow adding more fields to further-update the MultipartWriter instance
Are there changes in behavior for the user?
Users may reuse the FormData instance without the need of creating a new instance for every form-data requests.
Related issue number
n/a
Checklist
- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [x] If you provide code modification, please add yourself to
CONTRIBUTORS.txt
- The format is <Name> <Surname>.
- Please keep alphabetical order, the file is sorted by names.
- [x] Add a new news fragment into the
CHANGES
folder- name it
<issue_id>.<type>
for example (588.bugfix) - if you don't have an
issue_id
change it to the pr id after creating the pr - ensure type is one of the following:
-
.feature
: Signifying a new feature. -
.bugfix
: Signifying a bug fix. -
.doc
: Signifying a documentation improvement. -
.removal
: Signifying a deprecation or removal of public API. -
.misc
: A ticket has been closed, but it is not of interest to users.
-
- Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."
- name it