Aiohttp new release

Hi! We have to use a custom build of aiohttp because we need some functionality from the master branch.
I have 3 questions

  1. Do you have any ETA for 4.0?
  2. Do you have any ETA for 3.6.3/3.7?
  3. How to include this commit into 3.6.3/3.7 release?

Thanks!

Thanks for raising the question.

  1. For 4.0 I have no ETA, it is not ready yet.
  2. For upcoming 3.7 the main blocker is that aiohttp doesn’t pass all tests on Python 3.8. I recall there are Windows fails: https://github.com/aio-libs/aiohttp/pull/4410
  3. The mentioned commit was backported to 3.7 branch and will be a part of aiohttp 3.7 release. Please check if this branch works for you.

Ah, the branch 3.7 means the aiohttp version, not the python one :slight_smile:
However, I do not use windows at all but how can I reproduce failed tests? The build from #4410 is deleted, so no logs.

  • git checkout 3.7
  • git cherry-pick from #4410
  • create PR against 3.7
  • check output from CI
  • try to fix failed tests

Am I right?

Azure Pipelines deletes stale builds.

I’ve refreshed the branch for https://github.com/aio-libs/aiohttp/pull/4410 to bump the build system.

It looks like I figured out how to fix these tests https://github.com/aio-libs/aiohttp/pull/4463
Can we have 3.7.0 now?

Please let me review first.
Also I want to cope with several multipart bugs on the weekend.

Can you wait for a few days?

No, it’s not that urgent, please take your time.

Windows tests are okay now, what else blocks 3.7 release? AFAIR you want to rewrite starttls and sendfile things, am I right?

loop.sendfile() is used if available now.
I’m working of start_tls().
I have scratched the desired implementation but have a problem.
We have no reliable functional tests for proxies, need to make them first.

Also, I recall a PR for multipart encoding fix, need to review it and other pending pull requests.

Okay, thanks. I have some free time, so I can help (with some guidance/directions) if needed.

I have https://github.com/aio-libs/aiohttp/tree/native-start_tls branch (drop if False in connector.py to make start_tls used).
test_proxy.py should go away and test_proxy_functional.py should be refactored to follow design of test_client_functional.py: create a test server, start it under proxy, test client code. The same with TLS. This is the main idea, I want to prototype test proxy server soon.

Another problem that I want to fix is fields encoding in multipart forms.
Try the following gist and upload firstname/lastname/filename with non-ascii characters from a browser and aiohttp client (I used Russian).
I recall some problems with it, and people reported in aiohttp tracker for corrupted local names. This issue has very clean scope; I very appreciate if you can take it.

I tried to reproduce the bug from the gist, but I couldn’t. After I filled form via browser with Russian symbols and pressed submit, I got this

------------------------
------WebKitFormBoundaryEDFBJKF0jxcvFIS9
Content-Disposition: form-data; name="firstname"

привет
------WebKitFormBoundaryEDFBJKF0jxcvFIS9
Content-Disposition: form-data; name="lastname"

пока
------WebKitFormBoundaryEDFBJKF0jxcvFIS9
Content-Disposition: form-data; name="file"; filename="привет.пока"
Content-Type: application/octet-stream

привет

------WebKitFormBoundaryEDFBJKF0jxcvFIS9--

I tried to find an open issue with keyword form-data, but unfortunately no luck.
What am I doing wrong?