http_set_curlopt() works one time

I am using the latest release 1.2.3.

I noticed today that the http extension does not save the CURL options permanently (well, permanently within the session). I have entered a proxy with port and access data. But on the second call, an error message like host not resolved (from a company intranet) appears.

I can't exactly recreate the initial situation, but it's basically similar. I'm setting a proxy that doesn't exist. Then I expect on every call an error message that the proxy refuses the connection, but the error message only comes once:

jotpe=> select http_set_curlopt('CURLOPT_PROXY', '127.0.0.1');
 http_set_curlopt 
------------------
 t
(1 Zeile)

jotpe=> SELECT content FROM http_get('http://httpbin.org/ip');
FEHLER:  Failed to connect to 127.0.0.1 port 1080: Verbindungsaufbau abgelehnt
jotpe=> SELECT content FROM http_get('http://httpbin.org/ip');
          content           
----------------------------
 {"origin":"re.pl.ac.ed"}+
 
(1 Zeile)

[pramsey]

When set within a session on a particular backend, I'd hope the settings persist: the curl connection object is cached for the lifetime of the backend, and the settings are set there. Is it possible you're actually connecting to a couple separate backends?

The setting (http_set_curlopt) were made in one db session, but outside of a transaction. The http target url was very the same, in my current example.

jotpe=> select datname,datid,pid from pg_stat_activity where datname = 'jotpe';
 datname | datid |  pid  
---------+-------+-------
 jotpe   | 16385 | 14600
(1 Zeile)

jotpe=> select http_set_curlopt('CURLOPT_PROXY', '127.0.0.1');
 http_set_curlopt 
------------------
 t
(1 Zeile)

jotpe=> SELECT content FROM http_get('http://httpbin.org/ip');
FEHLER:  Failed to connect to 127.0.0.1 port 1080: Verbindungsaufbau abgelehnt
jotpe=> SELECT content FROM http_get('http://httpbin.org/ip');
          content           
----------------------------
 {"origin":"re.pl.ac.ed"}+
 
(1 Zeile)

jotpe=> select datname,datid,pid from pg_stat_activity where datname = 'jotpe';
 datname | datid |  pid  
---------+-------+-------
 jotpe   | 16385 | 14600
(1 Zeile)

In my original case, the host was always the same, only the HTTP GET parameters were set dynamically using a join table.

[pramsey]

Hm, I wonder if this is a side effect of the error...

[pramsey]

Yes, it is.

https://github.com/pramsey/pgsql-http/blob/master/http.c#L1001

So, question is how to deal with it. I hate the idea of managing my own list of options and re-setting them every time.

I tried several things, because in the past I did get it already running with the 'new' http_set_curlopt.
First I used the combined proxy string http://user:pass@proxy:80/. Maybe the multiple settings cause that behaviour.
And second, I set http.keepalive='on' and the settings are used multiple times.

Maybe passing the curl options by function parameter every time?

[pramsey]

Yeah, GUC's will persist, but I don't want to go down the route of having a GUC for every CURL parameter. I'm looking at having my own list of opts (yuck)

Cant GUC be dynamic? Maybe accepting any http.GUC, if there is a matching key in the curllib.