8.0.x -> 9.0.x broke my code about fshttp HOT 3 CLOSED

In the past releases, json set the content type to text/json - see #93 .

In general, the API is built up in a way that defining inconsistent requests is hard or impossible. E.g. defining a content type on a request without content is not possible. Technically, this is done by changing the underlying types defining the computation: There is a HeaderContext for specifying HTTP header. That context can be transformed using the body operation into a BodyContext or into a MultipartContext using the multipart operation, etc. On each context, there is a set of possible operations (see here: https://github.com/fsprojects/FsHttp/blob/master/src/FsHttp/Dsl.CE.fs). That's the reason why ContentType has to be places into the body.

from fshttp.

Thanks for posting the issue - it's valuable to have issues like that.

• 9.0.6 is released (including the changed from #100 - I forgot to bump the version; please excuse).
• There are indeed a lot of changes from <= v8 to v9. There are some general hints on how to migrate (which was not working until now). The linik is here: https://fsprojects.github.io/FsHttp/Migrations.html
• For this issue: There is a small sample with the code from above, transformed to work with v9: https://github.com/fsprojects/FsHttp/blob/master/src/fiddle/issue_101.fsx

Please see the comments:

#r "nuget: FsHttp"
open FsHttp

let getString url rjson = async {
    let! response =
        // See also: https://fsprojects.github.io/FsHttp/Migrations.html
        // 'httpAsync' is replaced by 'http { ... } |> Request.sendAsync'
        http {
            POST url
            Origin "Web3.fs"
            
            // a) 'ContentType' is an operation only valid
            //    on the reqiest 'body' definition.
            // b) Setting ContentType to 'application/json' is
            //    redundant when "json" operation is used.
            body
            ContentType "application/json"
            json rjson
            
            config_timeoutInSeconds 18.5
        }
        |> Request.sendAsync
    let! responseContent = response |> Response.toTextAsync
    return responseContent
}

// Instead of using 'asyn { ... }' CE, it sometimes is sufficient
// piping async 
let getStringAlternative url rjson =
    http {
        POST url
        Origin "Web3.fs"
            
        body
        json rjson
        ContentType "application/json"
            
        config_timeoutInSeconds 18.5
    }
    |> Request.sendAsync
    // use 'Async.await' that works like 'bind':
    |> Async.await Response.toTextAsync
    // use 'Async.map' to transform results in an async context:
    |> Async.map (fun text -> text.ToUpperInvariant())

from fshttp.

Excellent, thank you for the response. It wasn't obvious that the order of the items in the CE matters.
I seem to recall that, for my interaction, if I didn't explicitly set the ContentType I got weird behavior from my endpoint, but perhaps that won't be an issue in 9.0.x, I'll have a second look.

I appreciate the help.

from fshttp.