Contrib.social

Incompatibility with Guzzle HTTP >= 7.9

Open on Drupal.org →
Created on 25 July 2024, 9 months ago

Problem/Motivation

When posting a request to an API, Guzzle raises an exception resulting in a 500 Internal Server Error response and a message like "HTTP/HTTP/1.1 is not supported by the cURL handler."

Steps to reproduce

Upgrade GuzzleHttp to a version >= 7.9 and this will likely affect any request you care to make.

In HttpApiPluginBase::forward(), $options['version'] is set to $request->getProtocolVersion();
This retrieves $_SERVER['SERVER_PROTOCOL'] which is a string in the form 'HTTP/1.1'. Refer to https://www.php.net/manual/en/reserved.variables.server.php

This is sent to Guzzle as a request option where only the numeric element of the string is expected. Refer to https://docs.guzzlephp.org/en/stable/request-options.html#version

In the Guzzle CurlFactory::create() function, since version 7.9, there is a test 

        if ('2' === $protocolVersion || '2.0' === $protocolVersion) {
            if (!self::supportsHttp2()) {
                throw new ConnectException('HTTP/2 is supported by the cURL handler, however libcurl is built without HTTP/2 support.', $request);
            }
        } elseif ('1.0' !== $protocolVersion && '1.1' !== $protocolVersion) {
            throw new ConnectException(sprintf('HTTP/%s is not supported by the cURL handler.', $protocolVersion), $request);
        }

This raises an exception when api_proxy sends a request.

Proposed resolution

Strip off the 'HTTP/' prefix when retrieving the server protocol.

I have fixed this by overriding preprocessOutgoingRequestOptions() in my module and adding

    if (
      isset($options['version']) && 
      substr($options['version'], 0, 5) == 'HTTP/'
    )  {
      $options['version'] = substr($options['version'], 5);
    }

Remaining tasks

Patch api_proxy and release an update.

User interface changes

None

API changes

None

Data model changes

None

🐛 Bug report
Status

Active

Version

2.0

Component

Code

Created by

🇬🇧United Kingdom Jim Bacon

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @Jim Bacon
  • Comment 6 months ago →
    🇳🇱Netherlands boazpoolman

    I hate to come by and just say "same issue here", but that's about the gist of it.

    If I can assist with resolving the issue (with some guidance of the maintainer) feel free to reach out!

    For now we've just locked the `guzzlehttp/guzzle` library to 7.8.

  • Comment 4 months ago →
    🇺🇸United States adriancotter

    I had this issue with the update to Core 10.4
    I have used Jim's fix that for my custom module's plugins adding a preprocessOutgoingRequestOptions.

    For those of you who don't already have that function (like myself), that ends up looking like this:

    public function preprocessOutgoingRequestOptions(Request|array $options): array
  {
    if (
      isset($options['version']) &&
      substr($options['version'], 0, 5) == 'HTTP/'
    )  {
      $options['version'] = substr($options['version'], 5);
    }
    return $options;
  }
  • First commit to issue fork.
  • Merge request !14fix: patch for issue 3463730 - strip HTTP/ from version → (Open) created by Unnamed author
  • Comment 3 months ago →
    wotts

    Strangely enough, I can't reproduce the error even after updating Guzzle HTTP, but in any case I made a fork and here's also a patch:

  • Comment 27 days ago →
    🇺🇸United States jhedstrom Portland, OR

    We started seeing this as well, and once we applied the fix in #6, started seeing a different error, that may be related to this Guzzle upgrade:

    transfer closed with outstanding read data remaining

    This was specific to an API being called that set the header

    Transfer-Encoding: chunked

    Removing this header in our API proxy plugin resolved the issue.

  • Comment 25 days ago →
    🇷🇴Romania alex.stanciu

    Can confirm the problem appeared after an upgrade to Drupal 10.4 (which in turn bumped the Guzzle version) and patch #6 fixed the problem. Tested on multiple sites.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024