async-http-client
async-http-client copied to clipboard
HTTPClientRequest looks & feels like a value type but isn't
Sadly HTTPClientRequest contains a streamable body which is typically a reference to a (frequently) consume-once AsyncSequence. That means it's not actually a value type.
That's a major API winkle that should be fixed as soon as feasible.
My recommendation would be to separate the request and the body. Something like try await httpClient.execute(request, body: myStream).
Agree, same is true for the response. We should do it at the same time we adopt swift-http-types.
Indeed, swift-http-types adoption is the right cause of action here. Maybe we can even do this without a major then. Can we just deprecate HTTPClientRequest/Reponse and migrate to http types?
Currently yes but not after your PR has landed.
Currently HTTPClientRequest can be split into <Body: AsyncSequence>(HTTPRequest, Body) but afterwards it would be <Body: AsyncSequence>(HTTPRequest, Body, TLSConfiguration?).
Currently
HTTPClientRequestcan be split into<Body: AsyncSequence>(HTTPRequest, Body)but afterwards it would be<Body: AsyncSequence>(HTTPRequest, Body, TLSConfiguration?).
Cool, that seems to work either way.
It doesn't scale well. Why is TLSConfiguration now an argument but the rest of the HTTPClient.Configuration not?
I think your proposed solution in https://github.com/swift-server/async-http-client/issues/392 is the way forward with the exception that tier 3 is just (HTTPRequest, Body) which is given to tier 2 to execute.
If you want to change the TLSConfiguration you just mutate a local copy of your tier 2 value.
It doesn't scale well. Why is
TLSConfigurationnow an argument but the rest of theHTTPClient.Configurationnot? I think the your proposed solution in #392 is the way forward with the exception that tier 3 is just(HTTPRequest, Body)which is given to tier 2 to execute. If you want to change theTLSConfigurationyou just mutate a local copy of your tier 2 value.
Right, there's still an API-design challenge but #709 doesn't change anything about it because it amends the to-be-deprecated HTTPClientRequest.
Agree, same is true for the response. We should do it at the same time we adopt
swift-http-types.
Hi @dnadoba! Is this the issue that I should subscribe to for swift-http-types adoption or is there a separate issue?
That’s the right issue to track :)