incorrect operation with uvloop

[r00t-Taurus]

Describe the bug

When using the proxy parameter with uvloop I get the RuntimeWarning: An HTTPS request is being sent through an HTTPS proxy. This support for TLS in TLS although the request is made without errors and the IP is changed, does this warning affect anything?

To Reproduce

async def main():
    async with ClientSession(
            json_serialize=ujson.dumps,
            timeout=aiohttp.ClientTimeout(total=6),
    ) as session:
        async with session.get(
                "https://api.ipify.org?format=json",
                proxy="http://proxy",
        ) as response:
            print((await response.json()))


if __name__ == "__main__":
    uvloop.install()
    asyncio.run(main(), debug=True)

RuntimeWarning: An HTTPS request is being sent through an HTTPS proxy. This support for TLS in TLS is known to be disabled in the stdlib asyncio. This is why you'll probably see an error in the log below.

It is possible to enable it via monkeypatching under Python 3.7 or higher. For more details, see:
* https://bugs.python.org/issue37179
* https://github.com/python/cpython/pull/28073

You can temporarily patch this as follows:
* https://docs.aiohttp.org/en/stable/client_advanced.html#proxy-support
* https://github.com/aio-libs/aiohttp/discussions/6044

  _, proto = await self._create_proxy_connection(req, traces, timeout)
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

If you make a request without uvloop, the warning does not appear

async def main():
    async with ClientSession(
            json_serialize=ujson.dumps,
            timeout=aiohttp.ClientTimeout(total=6),
    ) as session:
        async with session.get(
                "https://api.ipify.org?format=json",
                proxy="http://proxy",
        ) as response:
            print((await response.json()))


if __name__ == "__main__":
    # uvloop.install()
    asyncio.run(main(), debug=True)

Expected behavior

I expected that there would be no warning when using uvloop

Logs/tracebacks

-

Python Version

$ python --version
3.11.5

aiohttp Version

$ python -m pip show aiohttp
3.8.6

multidict Version

$ python -m pip show multidict
6.0.4

yarl Version

$ python -m pip show yarl
1.9.2

OS

macOS/ubuntu

Related component

Client

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[Skimige]

I am using Python 3.12 with uvicorn = {version = "^0.25.0", extras = ["standard"]} (which introduces uvloop 0.19.0), and I think this is the exact issue I am facing with.

I added a print() in _warn_about_tls_in_tls() for the underlying_transport's type and confirmed it's uvloop.

<class 'uvloop.loop.TCPTransport'>

The warning is a bit annoying. I'd appreciate it if this can be fixed.

[Dreamsorcerer]

I think the check for that warning uses some implementation detail in asyncio, so I guess that's why it trips when uvloop is used.
@webknjaz probably knows more; Do you think we can remove this warning now, or change the condition to a simple version check?

[webknjaz]

@Dreamsorcerer looks like you're right: MagicStack/uvloop#588.

Disclaimer: following is my recollection but the memories are likely skewed.

I don't remember all the quirks around this, unfortunately. It was around time when aiohttp was dropping Python 3.6, but stdlib "kinda supported" TLS in TLS in all the places if this private _start_tls_compatible attribute was to be truthy but it was disabled in a way that stdlib always had it as False (unless monkeypatched externally which was a middle ground I chose to rely on since some RH products, Satellite I think, needed this and asked me for; they actually wanted it under Python 3.6 but that wasn't realistically doable, as I recall). At the time, it looked like Python 3.11 would start supporting this fully and officially but there was no certainty. And I know that some GNU/Linux distros tend to backport patches from newer versions of CPython that weren't necessarily mere bugfixes (at least, this was a practice observed in RHEL the past, I don't know if this is still the case). So I regard making runtime feature checks more reliable, than Python version checks in many instances. Additionally, non-CPython implementations may also diverse in what features they provide.

I haven't checked this in a long time but I was under impression that Python 3.11 didn't end up enabling this. Perhaps Python 3.12 did. Somebody needs to dedicate a substantial amount of time to re-familiarize with this bit of the code base to be able to make a better judgement...
It's not something that I use so I don't think I'll be able to do this myself anytime soon. But if somebody sends a PR, I could take a look.

@Skimige FWIW Python's default warning filtering allows end-users to ignore them. So it should be fairly straightforward to suppress it.

[webknjaz]

I suppose we could drop the warning and always set underlying_transport._start_tls_compatible = True for Python < 3.11. Though, I don't know if there would be any side effects, especially with third party event loops.