Async config_transformHttpRequestMessage about fshttp HOT 6 CLOSED

Hi @queil , thanks for the issue.

What's the purpose of having an async message transformer? I could think of such an example:

let request = task {
    let! theContent = File.ReadAllTextAsync("c:/temp/content.txt")
    return! http {
        GET "https://www.wikipedia.de"
        config_transformHttpRequestMessage (fun msg ->
            do msg.Content <- new StringContent(theContent)
            msg
        )
    }
}

What we can see in the example is: As soon as an async-fetched value is used in request definition (no matter if it's a header, content, transformer, config value, etc.), the whole request definition has to be lifted to async. It does not matter whether the asynchronous call occurs before the request definition (like in this example) or within - the effect is always the same.

This would require the internal implementation to be based on async - and I mean all of the internals. This is something that I think is not practicable, since the definition of a request is just data, and if a value is based on e.g. IO, it's always possible wrapping the request definition in a task (and being honest about that fact that it's async).

from fshttp.

@RonaldSchlenker Thanks for your response. I have a use case in which I asynchronously read request's content and store it (also asynchronously) in a data store before sending. Then such a logging function I can apply in multiple requests (think of a declarative HttpClientHandler). Does this make sense?

from fshttp.

That sounds to me pretty close to the example I posted above, isn’t it?

from fshttp.

The effect is technically the same in the sense, that yes, in both cases the code runs before the request. But this doesn't feel very elegant. I.e. I hoped to use it like a pipeline or middleware but I understand, as you said, that rewriting the whole internals to async just to support this is not very practical.

from fshttp.

If you want, you could provide a more complete example of how you think it could look like. Maybe there’s something in your idea which I don’t see.

from fshttp.

@RonaldSchlenker That's fine. I think I can solve it easily with DelegatingHandler.

from fshttp.