Option to Normalize HTTP_RESPONSE_HEADER Fields (Key Names) in the QSYS2 HTTP Functions

The HTTP header fields are case-insensitive. That is, content-type, CONTENT-TYPE, and CoNtEnT-tYpE are all allowed uses of the IANA registered field Content-Type.

Previously, when using the SYSTOOLS HTTP table functions (e.g., SYSTOOLS.HTTPGETCLOB), the HTTP response headers were returned in their native XML format. The XML response header could be parsed with the RPGLE op-code XML-INTO in a case-insensitive manner.

Now, when using the QSYS2 HTTP functions (e.g., QSYS2.HTTP_POST_VERBOSE), the HTTP response headers are returned as JSON. To parse the HTTP response, the SQL table function JSON_TABLE can be used. However, JSON path expressions used by the JSON_TABLE function are case-sensitive.

In my case, I am using the SQL HTTP functions to get data from business partners using RESTful API's. Depending on the partner we communicate with and even depending on the specific API call for the same vendor, the same HTTP response field may be coded with different casing. Furthermore, a change in the case of a header field (which, by definition is supposed to be case-insensitive) will break our production code.

Ideally, the QSYS2 HTTP functions should provide an option to upper-case or lower-case the HTTP response field names. This would allow for a consistent, case-insensitive parsing of the response headers. Additionally, any changes to the casing of an HTTP header field by our business partner would not break our production code.

Optionally, as the HTTP header fields are registered with IANA (see RFC 9110: HTTP Semantics and Hypertext Transfer Protocol (HTTP) Field Name Registry), the casing of fields that match a registered name could be aligned to the registered name casing. This would of course only solve the problem for registered field names.