HttpService only allows 3 in-flight requests at a time

To reproduce, run the following using Node.js:

let http = require("http");

http.createServer((_, response) => {
  setTimeout(() => {
    response.writeHead(200, { "Content-Type": "text/plain" });
    response.end("Hello, cruel world!");
  }, 10000);
}).listen(34733, "");

Then, in a fresh baseplate, run this in Roblox Studio’s command bar:

local HttpService = game:GetService("HttpService")
HttpService.HttpEnabled = true

for i = 1, 4  do
		local response = HttpService:GetAsync("")
		print(response .. " " .. i)

This results in output something like this:

  13:07:24.065  Hello, cruel world! 1  -  Edit
  13:07:24.066  Hello, cruel world! 2  -  Edit
  13:07:24.066  Hello, cruel world! 3  -  Edit
  13:07:34.081  Hello, cruel world! 4  -  Edit

We can see that the first three requests are made in quick succession and get responses after ten seconds (as expected), while the fourth request seems to get queued behind the first three, and is only sent once there are fewer than 3 requests in-flight. I’ve verified that this is indeed the case by analyzing my loopback traffic - here’s the zipped pcap: (1.4 KB).

This behavior occurs for further requests to any host, and the only way to clear this queue is to restart Roblox Studio. It seems related to this issue: HttpService extremely sluggish in studio.

This is specifically a problem for Rojo because it uses long polling, and it doesn’t have any logic implemented for cancelling open requests after a user disconnects. New users often rapidly disconnect from and reconnect to the Rojo server while trialing the software. Rojo only times out these long polls after a couple minutes, so after a user disconnects and reconnects 3 times, they have to wait a couple minutes before the Rojo plugin finally reconnects. When this happens, it seems to users that Rojo is very slow or “laggy” when the cause is really HttpService refusing to make more than 3 requests at a time.

Expected behavior

HttpService should be able to make more than 3 requests at a time. I’m not sure when this limit was added (I don’t recall it being a problem about a year ago), but I’d like it raised so it’s not so easy to trigger this queueing behavior. While Rojo could implement logic to close any open requests once a client disconnects, I still think a maximum of 3 requests is unreasonable, especially since this seems to be a global limit.


This is very interesting. I’m assuming the error persists in actual game sessions and not just Roblox Studio? Either way, having this limit removed would speed up multiple functions of my game.


Thanks for the report! We’ll follow up when there’s any update on the issue.

I think my issue isn’t exactly revolved around “3 requests at a time” but it seems related!

I’ll describe my case just to make sure it is applicable to this bug report. What I am doing right now is that I fetch from this api for every game a player has, so it is a recursive call to request from this api. I run these fetch requests concurrently. As for the http server, it handles them in a non-IO blocking way so I don’t think there’s an issue there.

I also saw that my requests taking an incrementally longer time the more of them I sent. This was obvious when testing in Studio. You can clearly see that there’s an uniform increment being added to each request. So I suspect that the requests were put on a queue or something.

taken in studio

And when testing in game servers, it was significantly faster and the increments were shorter but I could still see that they increasingly took more time individually, the more requests I sent. However, it doesn’t connected to an exact number of requests.

taken in game

1 Like

I have your exact use case and the exact same issue. Getting a user’s created game passes via this method will take up to seconds longer in Studio compared to in the game itself where it’ll be much faster. I’m not sure if this has the same root cause of the issue outlined in the OP, but it’s definitely something to do with the way HttpService works in Studio compared to in game servers. It’s not anything major because it doesn’t impact the core functionality, just extends the loading times a little, but it would be nice if the behaviour in Studio was consistent with that in-game.

I assume you’re using your own proxy or something like RoProxy to make these requests(?). Something I’ve noticed with the API endpoint you specified is with each request you make from the same IP, the more time it begins to take to return the results. You can test this by sending around 50 requests to the endpoint at the same time from a web server, where you’ll notice the behaviour is caused by the API itself and not the Roblox engine. I’m not sure if this is a rate limiting measure or a bug but it’d be nice to have it fixed as well.

1 Like

Thank you for this report. This is an intended limit for the feature. Unfortunately, this isn’t something we’re planning to change.

1 Like

Is it a limitation of HTTP/1.1? If so, can I ask why Roblox is blocked on upgrading to HTTP/2?