Problem/Motivation

The Drupal AI module currently does not support environments where requests must be routed through an HTTP/HTTPS proxy. Many organizations use proxies to secure and manage external communications, especially in development and corporate environments. Without proper proxy support, external API calls made by the module may fail, rendering the module unusable in these environments.

Steps to reproduce

1. Set up Drupal in a local or corporate environment where internet access is restricted and routed through an HTTP/HTTPS proxy.
2. Install and enable the Drupal AI module.
3. Attempt to setup OpenAI Authentication after adding OpenAI key .
4. Observe that the setup fails because the test request is not routed through the configured proxy.

Proposed resolution

- Update the Drupal AI module to support proxy configuration in `settings.php`.
- Leverage Drupal's `$settings['http_client_config']['proxy']` for both HTTP and HTTPS proxies.
- Include the ability to configure proxy authentication (if needed).
- Allow exceptions for certain local addresses (e.g., 127.0.0.1 or localhost) to bypass the proxy.

Remaining tasks

- Implement proxy support in the Drupal AI module's external requests handling.
- Write test cases for environments behind proxies.
- Update documentation to guide users on configuring proxy settings for the module.

User interface changes

No direct user interface changes are required for proxy support, but a settings option could be added to configure proxy settings via the admin interface (optional).

API changes

No API changes are required, but proxy support should integrate with the existing HTTP client configuration in Drupal.

Data model changes

No changes to the data model are required.

Comments

olegiv created an issue. See original summary.

mindaugasd’s picture

Hi @olegiv,

based on "Steps to reproduce" - proxy should already work if it is configured.

Observe that the setup fails because the test request is not routed through the configured proxy.

How did you configure it?

Here I pushed a code change which plugged Drupal HTTP client to OpenAI library.

So that middleware could be used, which enables change or log anything about HTTP request.

So with OpenAI you can already setup proxy by writing some middleware code:
* https://docs.guzzlephp.org/en/stable/request-options.html#proxy

Or setup in other way (depending how you did it), maybe some modules exists for that?

BUT for all other different providers you have to study case by case how the request is made in code, and if it does not use Drupal HTTP client, change to use it if possible (maybe push merge request like I did). Let me know what you find.

mindaugasd’s picture

If you really configured proxy, another thing to try -> turn off streaming feature.

Streaming may not be supported by proxy.

It is limitation of guzzle and/or PHP.

mindaugasd’s picture

By default guzzle use https://curl.se/, but for streaming it use PHP native streaming wrappers https://www.php.net/manual/en/wrappers.php, which has limited functionality and proxied requests, AI just said to me, are not supported.

Example issue on Github: https://github.com/guzzle/guzzle/issues/2616

mindaugasd’s picture

Or maybe it does support, proxy is listed as configuration option for http: https://www.php.net/manual/en/context.http.php

marcus_johansson’s picture

Is this issue still of interest - I would move it to the specific provider. OpenAI provider has a host variable now, so you can set a custom host. I will close this on the 4th of February otherwise.

wouters_f’s picture

Any outhgoing request using \Drupal::httpClient() wil normally take the proxy settings into account.
So if we are using guzzle directly and not the drupal client your issue might indeed be true.

We should use the drupal wrapper for every outhgoing request in orde to have everything working over a proxy.

wouters_f’s picture

If we use provider modules and we want them to support the proxy, we'll indeed need to add a proxy to the providers if they are using something else.

kevinquillen’s picture

So if we are using guzzle directly and not the drupal client your issue might indeed be true.

If I read this right, specifically with OpenAI, the OpenAI client library uses Guzzle and not the one from \Drupal::httpClient, which would preconfigure it properly.

https://github.com/openai-php/client/blob/main/src/Factory.php#L180

But, the AiProviderClientBase class is injecting an instance of a client from http_client_factory with options from the provider configuration:

  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    $client_options = $configuration['http_client_options'] ?? [];

    return new static(
      $plugin_id,
      $plugin_definition,
      $container->get('http_client_factory')->fromOptions($client_options + [
        'timeout' => 60,
      ]),

Which is then passed to the OpenAI wrapper to use as the Client:

https://git.drupalcode.org/project/ai_provider_openai/-/blob/1.1.x/src/P...

So I think the AI module(s) are doing the right thing here. I suppose one question is where is this configuration set, or does more need to be added to the provider to pass along for OPs needs?

$client_options = $configuration['http_client_options'] ?? [];

kevinquillen’s picture

I found an area where OpenAI\Client is used directly:

https://git.drupalcode.org/project/ai_provider_openai/-/blob/1.1.x/src/F...

mrdalesmith’s picture

That would need to be an issue in the Open AI provider's queue.

kevinquillen’s picture

Project: AI (Artificial Intelligence) » OpenAI Provider
Version: 1.0.0-alpha8 » 1.0.x-dev
mrdalesmith’s picture

That would be https://www.drupal.org/project/ai_provider_openai - the providers are no longer part of the AI core module