QSYS2.HTTP_GET takes the destination URL followed by a JSON options document. Its proxy address uses host,port, rather than a proxy URL. For an unauthenticated plain HTTP proxy, the options can look like this:

VALUES QSYS2.HTTP_GET(
  'https://api.example.net/status',
  '{"proxy":"proxy.example.net,8080",
    "proxySsl":"false",
    "headers":{"Accept":"application/json"}}'
);

proxySsl describes the connection to the proxy. IBM documents its default as true, so explicitly disable it when the listener expects plain HTTP. The destination in this example still uses HTTPS. For a permitted public-API test, an endpoint from the HTTP proxy list can fill the proxy host and port, formatted as the required comma-separated value.

Authentication has a separate boundary. proxyAuth is documented as userid,password and is allowed only when proxySsl is true. basicAuth supplies credentials for the destination service. An origin header or origin account cannot substitute for proxy authentication.

Supplying a username and password does not, by itself, select NTLM. The published SQL options do not provide an NTLM mechanism selector. If the proxy requires NTLM, establish whether that requirement is supported for the installed IBM i release and maintenance level before treating this credential field as a solution. Absence of a documented selector alone is not proof about every underlying implementation capability.

Also distinguish the two IBM SQL HTTP families. QSYS2’s functions use ILE technology; the older SYSTOOLS implementation uses Java. Installing a Java Authenticator for the SYSTOOLS path is not configuration for QSYS2’s native transport.

Match option availability, including the object form of headers, to the documentation for the installed release and PTF level. If a different transport is needed for the proxy’s required authentication scheme, choose one that explicitly documents that scheme.

Related articles