Sending a new http request from an action of a controller

I can’t figure out this:

Supporse I sent an additional http request in a new thread to a third-party website from an action titled “my_handler” of a controller.

And I return a result to a client, something like “ok” – not a result of sending that additional http request to a third-party website.


When a reply from that http request eventually comes back, would it hit “my_handler”?
If not, where and by what would it be received?

It depends on how you do the request.

If you do something like spawn(fn -> HTTP.get("") end) the result of the request will be lost.

If though you do something like spawn(fn -> "" |> HTTP.get() |> parse_data_out_of_website() |> Repo.insert() end), it will be put into your database.

Weil, of course you might use asynchronous mechanisms of your HTTP client, then it depends… If you had shown some code it would be easier to reason about it.

My question isn’t about that.

It is: what entry point is used when a result comes to my machine? Is it the same action/url I sent my http request from?

In other words:

def my_handler(conn, params) do

    # send http request to in a new thread
    # ...............
     text(200, "")

Will “my_handler” be called again when a response from “” comes?

Will “my_handler” be called again when a response from “” comes?


1 Like

A response is not a request, so it will not hit your endpoint at all.

In HTTP a response is always sent on the very same connection that made the actual request. If responses were requiring a new connection and were to be actively made by the server, the internet wouldn’t work as it is today. Actually no responses were ever able to pass firewalls, NAT systems, Routers, etc.

FTP has gone through this, and there is still a lot of problems with people not understanding when to use active or passive mode (and I do neither, I just try until it works).

1 Like

What determines a connection to be the same? If 2 processes send 2 requests to the same host, url and port, how will the responses coming back to them be distinguished between each other?

TCP (which transports HTTP) is like a phonecall.

HTTP is a phonecall where you ask a question, get your answer back and then hang up immediately.

So your separate processes doing separate HTTP requests, are actually two different persons, calling the same callcenter and getting their response by different workers in the callcenter on the same line they used to call into the callcenter. This is how the system can distinguish between responses and associate them to the correct request.

Actually all this association does happen in the network stack of your operating system and your application will not be aware of it. It just gets the correct response on its “line”.

This is networking basics and should be understood by programmers regardless of the fact that they are working with networking stuff or not.

I have avoided to use actual networking terminology here, since I do confuse some of those words as well, and I am by far not an expert in networking (it was actually the main reason for failing my bachelor) but I understand the basics I need for my everyday job.