ureq update to 3.0.8

[tessus]

Due to the errors in the CI pipeline for the recent PR (updating ring), I looked into upgrading ureq.

While most of the tasks are trivial, error handling seems worse than before.

e.g.

match ureq::get("http://mypage.example.com/").call() {
    Ok(response) => { /* it worked */},
    Err(Error::Status(code, response)) => {
        /* the server returned an unexpected status
           code (such as 400, 500 etc) */
    }
    Err(_) => { /* some kind of io/transport error */ }
}

turned into:

match ureq::get("http://mypage.example.com/").call() {
    Ok(response) => { /* it worked */},
    Err(Error::StatusCode(code)) => {
        /* the server returned an unexpected status
           code (such as 400, 500 etc) */
    }
    Err(_) => { /* some kind of io/transport/etc error */ }
}

So how am I supposed to print the response message in case of an error as we are currently doing like so: https://github.com/orhun/rustypaste-cli/blob/master/src/upload.rs#L205-L209

With these issues and the fact that multipart is no longer maintained, I am not quite sure the current code is properly maintainable. Switching to a different http client (and which one to choose) might also turn out to be a nightmare. On the other side, I believe ureq might get support for multipart in the future.

Any ideas or suggestions?

[orhun]

Thanks for looking into this!

It is a bit tricky... Can you maybe report this to ureq upstream to get an idea of how to get the response value from that error? Otherwise, we can probably skip the response value for the sake of updating ureq which is not very good.

Switching to a different http client (and which one to choose) might also turn out to be a nightmare.

Are you saying because we are highly dependent on ureq functions? I believe it shouldn't be that hard, as long as we have a similar API to ureq. reqwest is not a bad option in my opinion.

I believe ureq might get support for multipart in the future.

I highly doubt that but let's see!

[tessus]

Can you maybe report this to ureq upstream

Will do.

Are you saying because we are highly dependent on ureq functions?

Not really. I remember I looked into replacing ureq in the past, but ran into a bunch of issues. Unfortunately I can't recall what they were. Maybe blocking (sync) vs async, error handling, ...
The current code is blocking and I also remember that argument handling was somehow complicated as the args are not accessible in Upoader (only the config, but not the arguments). But that's another story.

[tessus]

Here's the solution: algesten/ureq#997 (comment)

This means we'd have to do the error handling in the "success" branch. Not really a problem, but it's still a bigger refactor than just bumping the version number. ;-)

Well, maybe somebody gets bored and switches from ureq to reqwest in a PR. Who knows, it can happen, right.... One can dream.

[orhun]

Ah now I see why they removed the response from error... makes sense.

Maybe we can convert this to an issue and mark it as "help wanted"?

[tessus]

Yep, sounds good.

And the ureq dev mentioned again he might consider adding multipart. algesten/ureq#1033 (reply in thread)
Maybe you could also write a nice comment how great that would be. ;-)