How does HTTPAPI get the source EBCDIC CCSID?

[4144da]

I have a question. How does HTTPAPI recognize source EBCDIC CCSID? Does HTTPAPI convert the source EBCDIC CCSID to UTF-8 when sending HTTP request and convert UTF-8 to the EBCDIC CCSID when returning HTTP response back to the caller?

[Scott Klement]

Not exactly sure what is meant by "source ccsid".

HTTPAPI simply tells the system to convert from the "job's current CCSID" (which will use the default CCSID if 65535/hex is set as the job's ccsid) when translating from the local system to the network ccsid. It defaults to iso8859-1 (CCSID 819) for the network. If I were to do it all over again today, I would've made 1208 the default, but back in 2001 when HTTPAPI was first released UTF-8 support on IBM i wasn't as robust as it is today. And I won't change it in the distro now because it'd break compatibility for too many people's programs.

You can override the defaults for all programs by changing the CONFIG_H member and recompiling HTTPAPI.

Or you can change it on a per-program basis by calling http_setCCSIDs() or http_setOption (with the appropriate option for local or network ccsid).

[emaxt6]

If I were to do it all over again today, I would've made 1208 the default, but back in 2001 ....

Yeah UTF8 is really the common and ubiquitous way nowadays...
maybe would be nice to introduce in the stock header file a new wrapper routine called like "http_req_utf8" with in the prototype the strings declared as UTF8 and doing internally just a call to setup the local and remote as 1208 and leave the passed strings unchanged ?
Or still too ugly?
Would not break existing users but allow new users to avoid some acrobatics like

DCL-DS *N;
s1 VARCHAR(100);
s2 VARCHAR(100) CCSID(*UTF8) SAMEPOS(s1);
END-DS;

[emaxt6]

...or using the OVERLOAD to select implmentation, using the same final name, but changing the number/type of parameter to let it bind to a proper implementation? just to throw some thoughts around...

[Scott Klement]

...or using the OVERLOAD to select implmentation, using the same final name, but changing the number/type of parameter to let it bind to a proper implementation? just to throw some thoughts around...

OVERLOAD is for switching between different prototypes based on the parameters passed.

It has no impact whatsoever on the value of a variable, which is what a CCSID is in HTTPAPI. So this suggestion does not make sense.

[emaxt6]

Want I wanted to say is to see maybe the overload as an option to avoid an explicit additional name like an hypotetical "http_req_utf"

say to have

http_req_jobccsid(VARCHAR ...

http_req_utf(VARCHAR CCSID(*UTF8)

And a "http_req" prototype defined as overload over the aforementioned (in the supported OS versions), that when called the compiler will bind to the correct specialized procedure based on the client code used CCSID.

Or for simplicity, just adding an additional exposed prototype "http_req_utf" (implementing a wrapper over the existing methods, just doing local/remote utf setup) would be indeed straight and surely a nice to have thing already in the stock httpapi... just my 2c to ease client code just passing natively utf.... not a big deal, just a nice to have to simplify some situations.
thanks

[Scott Klement]

Code: Select all

http_setOption('net-ccsid': 1208);
http_req( .... )

Or put it in the configuration when you build HTTPAPI, so that it defaults to 1208.