Exposing SyncStream, AnyioStream, and TrioStream?

[rthalley]

Recently the stuff in "backends" got moved to "_backends", with backends themselves being exported by httpcore instead. This is fine! Dnspython implements a backend in order to override DNS resolution as part of its DNS-over-HTTPS support. My issue is that I am using the httpcore._backends.sync.SyncStream, httpcore._backends.anyio.AnyioStream, and httpcore._backends.trio.TrioStream classes that are now under the private parent _backends.

I'm wondering if these can either be exported by httpcore as well, or otherwise have my usage of them blessed, as I'd not like to make dnspython fragile, but I don't want to implement these classes myself if I don't have to!

Thanks,

/Bob (dnspython maintainer).

[tomchristie]

Dnspython implements a backend in order to override DNS resolution as part of its DNS-over-HTTPS support.

Oh that's really neat.

One other option that comes to mind here that I'd be interested in your take on: Is it possible to switch the codebase around so you're doing the DNS lookup first, and then calling super().connect_tcp(...) with the DNS'ed hostname etc.

[rthalley]

Switching it around would almost work! I didn't mention the other limitation I was working around in my backend, which is binding the local source port as well as source address. I'm not sure that being able to pick the local port is very important nowadays, but it's part of the API so I was trying to support it.

[tomchristie]

I didn't mention the other limitation I was working around in my backend, which is binding the local source port as well as source address.

Okay. Perhaps if we start with just the sync example, could you show me what you're currently doing, and then we can review that against the SyncBackend implementation so I can understand this more completely?

[tomchristie]

(Also feasible that I'm overcomplicating this, and we ought to just okay this)

[tomchristie]

I'm wondering if these can either be exported by httpcore as well

I think they probably could, yes.

We probably want...

• Listing those three classes in the docs. (The reference isn't very helpful at all there, but at least it describes what is exposed by the public API.)
• Adding them to the public API.

[rthalley]

Works for me! Are you asking for a PR?

[rthalley]

See class _NetworkBackend in dnspython's query.py module. The backend is instantiated by our own HttpTransport, that contains the extra info we care about (the "bootstrap address" and the local port, and packages it into the backend. The backend's job is to 1) deal with the bootstrap address, 2) do any DNS resolutions with dnspython instead of with the system's native stub resolver via socket.create_connection(), 3) create the underlying socket and bind the local address and port as specified.

Besides blessing what I'm doing, another way to meet my needs would be 1) allowing the DNS resolution to be overridden, or a list of addresses to use to be passed in, and 2) a way to specify local port as well as local address. I'd be happy with that, as then I wouldn't have to have my own. I realize my use case is not typical and won't feel bad if you decide it's better to leave me subclassing.

I am glad, however, that we're having a nice discussion about it, whichever way it ends up! Thanks!

/Bob