HTTP Request to a docker container

Hi folks,

i wonder how to properly do a http request to a docker container. My current libraries, which might matter are tokio and reqwest

Reqwest tells me, that URLs such as are not valid.

In fact here is the error, which describes the situation pretty well.

app_1 | 2021-05-27 15:59:38,908 WARN [user_service::repository] BaseURL: "http://auth-app:8000/"
app_1 | 2021-05-27 15:59:38,908 WARN [user_service::repository] Endpoint: "api/v1/login"
app_1 | 2021-05-27 15:59:38,908 TRACE [mio::poll] deregistering handle with poller
app_1 | thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: RelativeUrlWithoutBase', src/
app_1 | note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

What is a good way to communicate between docker container in e.g. a docker swam environment. Besides using message broker such as rabbitmq.

I would double-check that the domain is actually part of the url you are using. If you pass "api/v1/login" as the url to reqwest, you get that error.

I did double-check the url string:

log::warn!("BaseURL: {}",auth_service_base_url); // output: [user_service::repository] BaseURL: "http://auth-app:8000/api/v1/login"
let request_url_test = reqwest::Url::parse(&auth_service_base_url).unwrap(); // error here
log::warn!("Parsed URL: {}", request_url_test.into_string())

Results in following error:

user_app | 2021-06-15 11:53:22,818 WARN [user_service::repository] BaseURL: "http://auth-app:8000/api/v1/login"
user_app | thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: RelativeUrlWithoutBase', src/

What i did try is extending the hostname e.g. auth-app with a domain e.g. auth-app .com
and naming the container explicitly. Parsing did work. Since i want to address an Service this '.com' is really unnecessary and i was wondering why the parse function does not like the described url.

Communication with a docker container over http is no different than communicating with anything else over http. During development, I will often use the command-line curl as a sanity check to make sure I have my docker port mappings, environment variables, etc. set up properly before I assume the error is with my code: Something like

$ curl --header "Content-Type: application/json" \
  --request POST \
  --data '{"username":"xyz","password":"xyz"}' \

Specific to your instance, if your code is running inside a container that is part of the same swarm/deployment, you should be able to access your service simply via http:://containername:default_port. If it is not running inside the same deployment, you will have to use the ip address/port. Typically I check these with something like

sudo docker container ls | grep "auth-app"

You should see something like>8080

Hi Fabio, thanks for the response.

I did manage to track down the problem. tldr: wrong url string, because it was enclosed in "" since i read it from env.

Stuff i did, which led me to the problem:

i just tried to do this, because of your suggestion.

  1. entered my rust container
  2. curled following:

curl -X POST -H "Content-Type: application/json" -d '{"username":"mario", "guid":"123123"}' http://auth_app:8000/api

and got following correct response:


i would say this proves, that the communication channel between the two containers is working as indended. ( you gave me a hint tho. the url base name was auth-app instead of auth_app )

nonetheless: this didn't change the situation that my URL-String ist not parsed into a URL Object by the Reqwest library via the parse function.

i tried to setup a minimal example:

fn main() {
println!("Hello, world!");
let url = "http://auth_app:8000/api/v1/login";
let parsed_url = reqwest::Url::parse(&url).unwrap();
println!("{}", parsed_url);

this did work as expected. And i was wondering why. This led me to inspecting the types. In my appliation i was using 'String' but the parse function expects '&str'. Furthermore i was reading url from an env var.
The env var was enclosed by "" and therefore an invalid url :smiley:

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.