Normally, when you call the function game:HttpGetAsync() in a networked DataModel without setting the DebugAllowHttpInNetworkedDMs FFlag to true, you would get the following error:
However, the FFlag above only works in the Roblox Studio. In version v0.665.0.6650683 of the Android Roblox Client, setting that FFlag to true will still not allow the usage of game:HttpGetAsync() & game:HttpPostAsync().
I am not sure if this behavior is present in the Windows Roblox Client.
Expected behavior
I expect the function game:HttpGetAsync() to be usable in a networked DataModel (A DataModel that contains either a NetworkServer or NetworkClient Instance) in the Android Roblox Client when the FFlag DebugAllowHttpInNetworkedDMs is set to true.
Update: I have tested this in the Roblox Windows Client and can confirm that it also does not work in the Windows Client version-bef193a8f3d14d3c.
Edit: I’ve noticed that this thread/post was closed without any reason provided. If what I have reported was intentional and not a bug, please let me know. I would love to know the reason behind why this bug report was closed without any provided reason. Thanks! And no, this isn’t a troll post. I am simply looking for alternative functions that could be used to send HTTP requests to Roblox APIs in the client, basically looking for an alternative to HttpRbxApiService functions or HttpService:RequestInternal() and found that game:HttpGetAsync() could be a potential good alternative if the FFlag got rid of the error in the client.
This is by design to curb external exploits. On a side note, setting FFlags for the client should generally be avoided, and a future update will prevent it altogether.
I thought specific FFlags would be allowed to be used
Staff have given very mixed responses about this, but FFlags are pretty crucial to me and alot of my friends for performance (and sometimes development) reasons. If they are planned to be removed entirely will we be provided with more client settings as alternatives?
This is correct; certain FFlags will be allowed. However, the list of allowed FFlags is not finalized yet and, even after finalization, will be subject to change. Debug flags are less likely to end up on the allow list. Also, for Studio, FFlags will be allowed as usual.
On the topic, could you please clarify this? Losing client FFlags would be a great opportunity for Roblox to step in and offer more natively (eg. graphics options, client betas for features, etc.)
The changes have been discussed extensively here. In a nutshell, if a FFlag is necessary to be set by the user to elevate their experience, then the feature that the FFlag controls is a prime candidate for a setting in the client UI.
Thanks for the reply! It’s funny that the reason why I have been looking for an alternative function to send authenticated HTTP requests to Roblox APIs is because of the fact that HttpRbxApiService functions are blocked in the environment of executors and can not be used due to people (including me ) who take advantage of it by spreading scripts for Roblox Exploiters to execute that would just mess with their account and troll them, and I’ve found out that the actual HttpGetAsync or HttpPostAsync functions are not blocked in the executors likely because of the function throwing the error and the executor developers do not realize that it could also be abused to troll or play a prank with their users as it can send requests to Roblox APIs and include the authentication cookie of the account, I thought that I’ve just hit the jackpot but it turns out that the FFlag was actually made to not work in the client to combat against external executors. (If this worked, this would’ve been the 17th vulnerability I found in executors )
Also, I don’t think that preventing those 2 functions from being used in the client actually do much to combat against external executors, as the way that those executors such as Solara handle the situation is make a DataModel wrapper and change game.HttpGetAsync and game.HttpGet to a lua function that’s just a wrapper for HttpService:RequestInternal(). Additionally, maybe detecting if the RequestInternal function sends HTTP requests to suspicious URLs that CoreScripts would normally not send a request to, would be a great addition to detect exploiters?
) who take advantage of it by spreading scripts for Roblox Exploiters to execute that would just mess with their account and troll them, and I’ve found out that the actual HttpGetAsync or HttpPostAsync functions are not blocked in the executors likely because of the function throwing the error and the executor developers do not realize that it could also be abused to troll or play a prank with their users as it can send requests to Roblox APIs and include the authentication cookie of the account, I thought that I’ve just hit the jackpot but it turns out that the FFlag was actually made to not work in the client to combat against external executors. (If this worked, this would’ve been the 17th vulnerability I found in executors 
)