When toJson Fails (due to parsing error), the original Content is not shown in the exception so that Debugging is a hard thing to do.

• binary
• base64
• multipart

That smells like a bad sideeffect bug, propably somewhere in config.

#load @"./packages/SchlenkR.FsHttp/lib/netstandard2.0/FsHttp.fsx"

open FsHttp
open FsHttp.DslCE


post "https://reqres.in/api/users" {
    CacheControl "no-cache"
    body
    json """
    {
        "name": "morpheus",
        "job": "leader"
    }
    """
}

Should be deployed in the folders .netstandard2.0 etc, not in root lib

In FsHttp.fsx file, enhance the print function to have better Output and debug functionality.

Use

[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]

and restructure functions for response handling (no more AutoOpen)

Maybe instead of the FsHttp.fsx file, we could use FSharp.Compiler.Interactive.Settings.fsi object to register printer automatically once the assembly is loaded.

Hint: http/2 is only available in .Net Core 3 via HttpClient

Support all other builder methods (especially "for").

The includes don't Point to the correct directories according to the Location in the nuget package.

Following the instructions in
Setup (F# Interactive) section, but using dotnet fsi (.net core 3.0 preview 5), I get an error when executing a get - specifically ERROR reading response content: System.IO.FileNotFoundException: Could not load file or assembly 'FSharp.Data, Version=3.0.0.0

I needed to do the following to get it working:
> open FSharp.Data;;
> printfn "load module %A" JsonSaveOptions.None;;

After these 2 steps, the get "https://reqres.in/api/users?page=2&delay=3" .> go;; worked without error.

Not sure if you want this added to the instructions, or to wait and see if .net core 3.0 RTM rectifies the issue.

https://twitter.com/ITSecMedia/status/1295796560018767872

Let the user specify ways of dealing with SSL errors

Change the signature so that the header function can be used to add custom headers to the context.

When set explicitly as a Header field, the ContentType value is ignored when a request is sent. It is only used when a Body is specified via text or json content.

See here:

https://github.com/CompositionalIT/farmer/blob/5f00a163a57f2aac3bc6a899adb2515fc1e0368a/src/Farmer/Deploy.fs#L47

I'm using FsHttp to create http messages
This is a breaking change by updating a major version from 3.1.0 to 4.0.2.

let msg =
    httpMsg {
        GET "https://google.com"
    }

This expression was expected to have type
    'FsHttp.Domain.IContext'
but here has type
    'LazyHttpBuilder<FsHttp.Context.HeaderContext>'

I could be wrong, but I have expected such conversion should be in Run, not in Delay as it is right now
https://github.com/ronaldschlenker/FsHttp/blob/master/src/FsHttp/DslCE.fs#L42

Request.sendAsync doesn't start an asynchronous request. It only builds one that has to started afterwards.

Support a convenient way of specifying a Proxy + credentials.

When sending JSON with "body json", the Content-Type header is application/octet-stream.

Thank you for this nice library, with great ergonomics.

I've been playing around with retrying http requests. I found this snippet for retrying any async "work". I soon realised that the httpAsync { ... } async builder fires off the request as soon as it's evaluated, i.e. it's a "hot" task like in C# land, rather than the cold async task idiomatic to F#, so I had to do some additional wrapping, and this is what I eventually came up with FsHttp:

let request =
    async { return! httpAsync { GET "http://httpbin.org/status/500:4,200:1" } }

let! result = retry request (fun r -> int r.statusCode = 200) 10

My question is: am I using this library correctly or am I missing a way to solve this more gracefully? Below is the full runnable example, with a modified retry function which makes the code slightly better (albeit the retry is specialised for http and doesn't work for any async task anymore):

#r "nuget: SchlenkR.FsHttp, 5.0.0"

open FsHttp
open FsHttp.DslCE

let rec retry request resultOk retries =
    async {
        let! res = request |> Request.sendAsync

        if (resultOk res) || (retries = 0) then
            return res
        else
            return! retry request resultOk (retries - 1)
    }

async {
    let request =
        httpLazy { GET "http://httpbin.org/status/500:4,200:1" }

    let! result = retry request (fun r -> int r.statusCode = 200) 10
    printfn $"status code = {int result.statusCode}"
}
|> Async.RunSynchronously

Provide a possibility to specify a default timeout and a fine grained timeout per request.

Provide a convenient mechamism

formatting should be done in invariant culture (decimal separator issue)

Context parameter of all DSL methods should be the last one to enable chaining

Instead of havin http, httpAsync, httpLazy, etc., it could be beneficial to only have one builder that emits different result types (and controls execution) based on keywords. Currently, keywords control formatting (like "exp").

Since ASP.NET Core introduced IHttpClientFactory and its default DI container supports HttpClient injection out of the box, is it possible to combine it with these computation expressions and inject an instance of the client?