Remove proxy option

[PhMemmel]

Currently the code uses native php curl and has some additional logic to handle proxy settings including needing the admin to configure if proxies should be used or not.

Instead the moodle http_client class should be used which is a wrapper for a guzzle client. It will automatically respect the moodle internal proxy settings which should be far more stable and reduces the overhead of code that qtype_stack needs to maintain.

Additionally, there is a problem which could be considered as a qtype_stack bug somehow:

See the following setting:

• Machine has configured proxy settings, but misses out specifying which hosts should not be accessed via proxy
• Moodle proxy settings are applied properly including machines that should not be accessed via proxy
• For accessing the maxima server the connection needs to be direct (not using proxy)

In this scenario plain php curl will use the proxy settings of the environment which are wrong, so qtype_stack tries to reach the maxima server through the proxy even if the moodle settings (in both modes "Server" and "Server (proxy)" !!!) are properly configured.

Irritating setup bugs could be avoided if the moodle http_client class is being used. In this case the moodle proxy settings are always used.

[aharjula]

Do look at #1021.

In short, everyone does not want to use the Moodle proxy settings for internal communications of the system, nor do we really have any realistic need to push through that whole chain for internal services.

This is one of those places where I am perfectly happy to let "Server (proxy)" people proxy in whatever way they wish, but if someone forces the original "Server"-connector to waste cycles to check proxy settings that are not relevant, for that use case, I am going to get difficult.

I really don't see how we are going to stay green and lean and save the world when everyone wants to stack all their extra checks for use cases that trigger rarely on a pipeline that executes a fixed task that does not change after the setup. It would be an utter waste of cycles.

[PhMemmel]

Thank you for the feedback and pointing me to #1021.

I'm not sure you got me right there however. Two things I want to elaborate on:

• Moodle provides the http_client as a moodle specific library for external connections which all core functionalities are using (and IMO all plugins also should use). If a plugin does not use it, it will make network related debugging very hard, because noone expects STACK to do something different, if it's a moodle plugin. If I as an admin am setting the moodle proxy settings correctly I will expect stack to work out of the box and not expect it to have some separate internal logic which is not understandable. But that's just my view.
• Putting this basic thought aside: As you wrote, you do not want "Server" to cycle through proxy etc. I also would expect this mode to run with a direct connection and no proxy at all, HOWEVER: IT CURRENTLY DOES NOT. Instead, it will still use proxy proxy settings of the webserver's underlying OS. I would however expect that in this setting the server option would disable the use of a proxy completely which is not the case.

I understand your point wanting to keep both modes "Server" and "Server (Proxy)" (even if I do not really agree). However, I still suggest to implement "Server (Proxy)" with http_client and force "Server" mode to explicitly disable the proxy in the curl call completely in this case.

Don't want to open up a fundamental debate here, as it has already been done in #1021 apparently, just sharing my 2 cents :) Thanks for considering!

[aharjula]

The thing is that proxies have a role, and that role is particularly relevant when we deal with requests to addresses outside the installation or addresses formed or extracted from user input. Such a proxy would obviously also be configured to stop attempts to read behind the curtain by using the proxy as a proxy.

The "Server" connection inside STACK, however, is neither of those; it connects to a separate server, typically running inside the installation, i.e., behind that curtain (it should never exist outside or be under untrusted control), in a fixed address and pushes API requests to that address, and those requests have no need for a Moodle-managed proxy to do anything to them. There might exist load-balancers and caching proxies at the end of that address; there is no need for further loading of it. The key thing is that it is a fixed latency-sensitive thing that, if at all possible, should not need to go through any extra proxies. A single quiz submission style request from a student may trigger dozens of subrequests to that address, and if every one of those now has a millisecond class extra cost to it due to that pointless proxy, it does start to become human detectable, not to mention generating load for the proxy itself. Sure, you can then have a proxybypass setting to opt out of that, but why waste time checking that bypass for every single one of those subrequests, when you already know that a thing will not go through the proxy?

And finally, "Server" connectors are not used in all STACK installs, only in the big ones where people tend to think about the implications and fine-tune things. In those, you do not push things through proxies unless you need to and you tend to have different types of proxies for different tasks.

In any case, feel free to modify the "Server (proxy)" thing to use whatever proxy thing you wish.

But the "Server" one must stay as it is. If it is being forced to a separate proxy by server-level settings, then that is a parallel control option for those who do not want to push through the Moodle proxy setup. Anyway, it has been a very long time since anyone has even mentioned applying OS level proxy settings, or CURL settings for that matter. It sounds like a configuration nightmare. I do wonder how many people actually set those and then don't manage to understand why things end up going there.