Module fails to handle stream-contexts

Created on 25 July 2019, over 5 years ago
Updated 11 November 2024, about 1 month ago

The Relaxed module β†’ leverages stream-context to help connect to remotes in the process of deploying content between environments. This stream-context is provided by https://github.com/relaxedws/couchdb-client/blob/master/lib/Doctrine/Cou... ->checkConnection() line 91-105. The fopen() on line 106 gets passed through remote_stream_wrapper's HttpStreamWrapper->stream_open(). The stream context ends up inside of $options but doesn't get added in any way to $this->config that gets passed to guzzle in HttpStreamWrapper->request().

I tried to manually add the information from the provided stream-context into $this->config manually as per https://markoivancic.from.hr/set-the-authorization-bearer-header-in-guzz..., and set $this->config['stream'] = true, but in the end my deployments still fail.

πŸ› Bug report
Status

Active

Version

2.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States mrweiner

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡¦Ukraine pingwin4eg Zaporizhia πŸ‡ΊπŸ‡¦

    $this->config['stream'] = true

    This is incorrect approach since this way guzzle uses stream wrapper, leading to an indefinite recursion: remote stream wrapper -> guzzle -> remote stream wrapper...

    I did some investigation regarding context options, and I think it's possible to provide the method, headers and probably some other options from the stream context (stream_context_get_options($this->context)) to guzzle's request() $options, but I'm not sure about all of them (not even sure it's possible, but I'm not an expert in this field).

    There's a separate issue for remote_stream_wrapper:7.x-1.x-dev - #2522056: Use the native PHP stream wrapper if available. β†’ . It tries to achieve the same (or at least similar) goal using a different approach - "by wrapping the wrapper" if I understand it correctly. Maybe that is a better way, but as I see from comments - still not everything is possible.

    This issue summary needs update to be more general and clear. But considering my observations I don't know whether the issue should try to work out all the context options, or not, and in which way.

  • πŸ‡ΊπŸ‡¦Ukraine pingwin4eg Zaporizhia πŸ‡ΊπŸ‡¦

    I've been thinking about this, and now I see 2 reasons to actually switch from guzzle to a "wrapper in wrapper" way:

    1. As http_client service can be swapped with another one, it is unclear if another service would use same option names as guzzle.
    2. If I understand correctly, guzzle fetches the whole response at once, so using streams could be better in terms of performance (time, memory).

    Fix me if I'm wrong.

Production build 0.71.5 2024