Page 1 of 1

Problem with Basic Authentication in HTTPAPI v1.53

Posted: Mon Feb 16, 2026 9:48 pm
by kwengert
Hi,

I'm having an issue that I have'nt seen before. I've been using various versions of HTTPAPI for the last decade. I'm using the latest release to send a json payload to an endpoing using httpapi 1.53. The debug log appears to have the basic authentication in the header, but I"m getting a 401 error. Here are a couple of snippets of the log:

Code: Select all

HTTPAPI Ver 1.53 released 2025-10-15
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R4M0

http_setauth(): entered
New iconv() objects set, PostRem=1208. PostLoc=0. ProtRem=819. ProtLoc=0
http_persist_open(): entered
http_long_ParseURL(): entered
DNS resolver retrans: 2
DNS resolver retry  : 2
DNS resolver options: x'00000136'
DNS default domain: LIPARI.LOCAL
DNS server found: 172.29.2.4
DNS server found: 172.28.7.6
Nagle's algorithm (TCP_NODELAY) disabled.
SNI hostname set to: liparifoodstest.perform.descartes.com
-------------------------------------------------------------------------------------
Dump of server-side certificate information:
-------------------------------------------------------------------------------------
Cert Validation Code = 0
-----BEGIN CERTIFICATE-----
MIIHfTCCBmWgAwIBAgIQBv/4VIicHBHcuC1LZyb1zzANBgkqhkiG9w0BAQsFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMR0wGwYDVQQDExRUaGF3dGUgVExTIFJTQSBDQSBHMTAe
Fw0yNTAyMjcwMDAwMDBaFw0yNjAzMzAyMzU5NTlaMH8xCzAJBgNVBAYTAkNBMRAw
DgYDVQQIEwdPbnRhcmlvMREwDwYDVQQHEwhXYXRlcmxvbzEpMCcGA1UEChMgVGhl
IERlc2NhcnRlcyBTeXN0ZW1zIEdyb3VwIEluYy4xIDAeBgNVBAMMFyoucGVyZm9y
bS5kZXNjYXJ0ZXMuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
8AKXGiIXBi98H6asjGLMnmti2zMN0dTXYBm9I9/xN6piv69QNs5qtzqNsxAv7nUN
7Q/ZlsX91pnrQ4QUSCOkHBHs3S+C+B7xmrRTcCLpmCWOe5KZ67bT72oBMSK6agN/
m7eyeag1uUdBVJektm6V6eYYGMVNfW1P4sbzEeDK70D/POR9p649viZXNtNYT6S/
V4rk6cxXY45uRGMjNYxH2nU05SJMsHi2RFlyG9tPYVct3GTmaqFHsAgfidE8j5wn
lRHZzg2UOeXQ0UExQGoH3uVz/GRmcfMyMkehXuoDySVRI2NBbKOEQH0AayMbWS4N
JXDDOYjpxetNDhfujqTGU7FqihkB8L1Fh/4gafS3CEY5Pl5gvzp868cPSDV+OWBZ
2OR9E671iHlpOPerAvIfMptGSy6lnJLMSjtHe8Fb9Ctmj4heG3Gr1rcBhW/+selk
3BAnMknVQenTlPnQgNdg2cGzAZtpCYLNnel8XinzQMI4NV1nkXuo3/zJ34ezjava
FQDN3oPJbO4bYOm5aLTiEWJvt+AS/WIC+GVLibAGHhxG6T8rBVjZNXRRM3wfeDfZ
6OgEJVhvwStwTCMd9nxR9UFoxlv4998de3ghdhckKYT77q7MsbPZrhdsBIvqT/Ws
UlCJ9QwzjkpC8Iq1aidlajjMYqlE/HS0wdYIYDioQLsCAwEAAaOCAxQwggMQMB8G
A1UdIwQYMBaAFKWM/jLM6w8s1BnGCLgAJIhdw8W3MB0GA1UdDgQWBBSiKd/IQ42I
qgEWTWmQgZTLnz8ldjAiBgNVHREEGzAZghcqLnBlcmZvcm0uZGVzY2FydGVzLmNv
bTA+BgNVHSAENzA1MDMGBmeBDAECAjApMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3
LmRpZ2ljZXJ0LmNvbS9DUFMwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG
AQUFBwMBBggrBgEFBQcDAjA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY2RwLnRo
YXd0ZS5jb20vVGhhd3RlVExTUlNBQ0FHMS5jcmwwcAYIKwYBBQUHAQEEZDBiMCQG
CCsGAQUFBzABhhhodHRwOi8vc3RhdHVzLnRoYXd0ZS5jb20wOgYIKwYBBQUHMAKG
Lmh0dHA6Ly9jYWNlcnRzLnRoYXd0ZS5jb20vVGhhd3RlVExTUlNBQ0FHMS5jcnQw
DAYDVR0TAQH/BAIwADCCAXwGCisGAQQB1nkCBAIEggFsBIIBaAFmAHUADleUvPOu
qT4zGyyZB7P3kN+bwj1xMiXdIaklrGHFTiEAAAGVSLZwSgAABAMARjBEAiB/Aken
ToMQjW5SYWMT3Ti/47+aaOOvKNOfaJPC6LobDwIgNb5qRNCqfaYKcRy7KISS9OtR
3i/LkH/NxOUyXS5ivmAAdQBkEcRspBLsp4kcogIuALyrTygH1B41J6vq/tUDyX3N
8AAAAZVItnCIAAAEAwBGMEQCIH2wW4rYNb2mdemEvXV2FHJ8CclYCyRJSVUxAXyu
/RTcAiAiHAT1vF7FYvL0EdM3IrNrfOwg0XkULQxuhPbSPn0N0gB2AEmcm2neHXzs
/DbezYdkprhbrwqHgBnRVVL76esp3fjDAAABlUi2cJsAAAQDAEcwRQIhANZRtvrE
PQ2W4r9aNMC4gGaPAGhlFKH72/qwWYGBDMlRAiAn0SbAgxkYY7i0XV7g+D28ZOOT
WUxoTczr3XBCvPwJGDANBgkqhkiG9w0BAQsFAAOCAQEAfyW4j9KJhSvoFMg/afPk
9L89RwC64iT6RwLtdmwCGRoaanFhps5yZMdPKn15xMzBQcMxTse+5WRMVqIRgJtt
jJ+Zcawg1bAwfw02Mk1IiXYiGCQ10lzhey42fdO+Gggun8nrqDqR1NkiIAg/sWtx
w46Xp/KIAIj/ChQ9/cg4hZkV1FQltuwHpH4EltjVuUdk9lAOe2VciQeTJBW2QHt+
fQw+sz4u22Wrbz/VAdh2MC+jZ02g+YcoJZzRUgOR2OxtctKWhX7arEz5QGY0bp8Y
gY3EGrPoF4MzgWS/W47IgzuSGXDsFvmFFiu8rs9xI8lq8VJXKv0274+SzTKnVi5p
3A==
-----END CERTIFICATE-----
Serial Number: 06:FF:F8:54:88:9C:1C:11:DC:B8:2D:4B:67:26:F5:CF
Common Name: *.perform.descartes.com
Country: CA
State/Province: Ontario
Locality: Waterloo
Org Unit: The Descartes Systems Group Inc.
Issuer CN: Thawte TLS RSA CA G1
Issuer Country: US
Issuer Org: DigiCert Inc
Issuer Org Unit: www.digicert.com
Version: 3
not before: 20250226190000
Unknown Field: 19:00:00 26-02-2025
not after: 20260330195959
Unknown Field: 19:59:59 30-03-2026
pub key alg: 1.2.840.113549.1.1.1
signature algorithm: 1.2.840.113549.1.1.11
Unknown Field: 0382020F003082020A0282020100F002971A2217062F7C1FA6AC8C62CC9E6B62DB330DD1D4D76019BD23DFF137AA62BFAF5036CE6AB73A8DB3102FEE750DED0FD996C5FDD699EB4384144823A41C11ECDD2F82F81EF19AB4537022E998258E7B9299EBB6D3EF6A013122BA6A037F9BB7B279A835B947415497A4B66E95E9E61818C54D7D6D4FE2C6F311E0CAEF40FF3CE47DA7AE3DBE265736D3584FA4BF578AE4E9CC57638E6E446323358C47DA7534E5224CB078B64459721BDB4F61572DDC64E66AA147B0081F89D13C8F9C279511D9CE0D9439E5D0D14131406A07DEE573FC646671F3323247A15EEA03C925512363416CA384407D006B231B592E0D2570C33988E9C5EB4D0E17EE8EA4C653B16A8A1901F0BD4587FE2069F4B70846393E5E60BF3A7CEBC70F48357E396059D8E47D13AEF588796938F7AB02F21F329B464B2EA59C92CC4A3B477BC15BF42B668F885E1B71ABD6B701856FFEB1E964DC10273249D541E9D394F9D080D760D9C1B3019B690982CD9DE97C5E29F340C238355D67917BA8DFFCC9DF87B38DABDA1500CDDE83C96CEE1B60E9B968B4E211626FB7E012FD6202F8654B89B0061E1C46E93F2B0558D9357451337C1F7837D9E8E80425586FC12B704C231DF67C51F54168C65BF8F7DF1D7B78217617242984FBEEAECCB1B3D9AE176C048BEA4FF5AC525089F50C338E4A42F08AB56A27656A38CC62A944FC74B4C1D6086038A840BB0203010001
Unknown Field: 4096
Unknown Field: 79695B5387A85D9A56E2A9552967F69A
Unknown Field: 1.2.840.113549.2.5
Unknown Field: 9D6D553947696FB7C6D851C8E4F74570395A6FB4
Unknown Field: 88159BB326FB7E7D578C1AE98C1A16F1CC0494F37A763D84A958CD41F45FD37D
Unknown Field: 5
Unknown Field: *.perform.descartes.com
Unknown Field: 0
Unknown Field: 1.3.6.1.5.5.7.3.2
Unknown Field: 1.3.6.1.5.5.7.3.1
Unknown Field: 2.23.140.1.2.2
Unknown Field: http://cdp.thawte.com/ThawteTLSRSACAG1.crl
Unknown Field: http://cacerts.thawte.com/ThawteTLSRSACAG1.crt
Unknown Field: http://status.thawte.com

Protocol Used: TLS Version 1.3
http_persist_req(POST) entered.
http_long_ParseURL(): entered
http_long_ParseURL(): entered
do_oper(POST): entered
There are 0 cookies in the cache
POST /rest/request/AddOrderAndCustomerRequest HTTP/1.1
Host: liparifoodstest.perform.descartes.com
User-Agent: http-api/1.39
Content-Type: application/json

Accept: application/json
Content-Length: 3071
Authorization: Basic XXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXX is the redacted base64 userid and password.

Here is the end of the log:

Code: Select all

recvresp(): entered
HTTP/1.1 401 Unauthorized
Date: Sun, 15 Feb 2026 21:41:22 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Security-Policy: upgrade-insecure-requests;frame-ancestors 'self'
Permissions-Policy: payment=()
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 0


SetError() #13: HTTP/1.1 401 Unauthorized
recvresp(): end with 401
recvdoc parms: identity 0
SetError() #36: This page requires a user-id & password
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
recvdoc(): Receiving 0 bytes.
recvdoc(): Nothing to receive, exiting...
SetError() #36: This page requires a user-id & password
http_close(): entered
HTTPAPI Ver 1.53 released 2025-10-15
NTLM Ver 1.4.0 released 2014-12-22
OS/400 Ver V7R4M0

http_setauth(): entered
Here is the code trying to transmit the file:

Code: Select all

          URL = %Trim(SHHST) + %Trim(SHIDR);
          http_setauth(HTTP_AUTH_BASIC:%Trim(SHUSR):%Trim(SHPWD));
          // Set Accept header
          http_setOption('Accept': 'application/json');
          http_setOption('network-ccsid':'1208');
          http_setOption('timeout'    : %Trim(%Char(HTTP_TIMEOUT)));
          http_setOption('user-agent' : %Trim(%Char(HTTP_USERAGENT)));
          // wDatarc = http_url_post_stmf(%Trim(URL)
          //         : %Trim(pFile)
          //         : wResponseFile
          //         : HTTP_TIMEOUT
          //         : HTTP_USERAGENT
          //         : 'application/json' + wCRLF);
          Monitor;
          http_stmf('POST'
                  : %Trim(URL)
                  : %Trim(wResponseFile)
                  : %Trim(pFile)
                  : 'application/json' + wCRLF);
          On-Error *all;
            wError = *On;
          EndMon;
          http_setauth(http_auth_none:'':'');
I've changed the endpoint to a webhook.site account so I can view the actual header going out. This is what I see there. It appears that even though the Authentication appears in the log, it is not in the header when it gets to the destination. What I see on webhook.site is included as an attachment. It doens't appear that the Authorization is in the header, even though it appears in the log,

Any help would be greatly appreciated.

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Sat Feb 21, 2026 2:57 am
by Scott Klement
There should be a header 'www-authenticate' that tells the caller what type of authentication methods the server supports.

However, there isn't one in your log. To me, this means that it is not expecting BASIC, DIGEST or NTLM2 authorization. It is either expecting some other completely different type of authorization, or is using the 401 code for a different purpose such as notifying you of an authority error.

You need to get documentation for the site, or talk to a site expert, to understand what is expected.

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Mon Feb 23, 2026 7:03 pm
by kwengert
Hi Scott,

Thanks so much for your reply. There is another twist to this. We are able to send the file via Postman without issue from a PC on the same network as the IBM i using basic authentication. It almost seems that something on the IBM i is stripping the authentication from the header. I understand that is possible as a security precaution because the password can easily be decoded. Does that make any sense to you?

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Mon Feb 23, 2026 7:14 pm
by Scott Klement
There's nothing in the IBM i operating system that strips authentication headers.

Furthermore, I can see "Authorization: Basic XXXXXXXXXXXXXXXXXXXX" being sent with your request, so it is definitely being sent.

It's possible that the webhook.site you are running in through could be stripping them, but it wouldn't happen when you're not going through that.

Another thing to look out for: Remember that your data will be translated from your job CCSID (EBCDIC) to the network CCSID (either ASCII or Unicode). Please be sure you aren't using characters that are being mistranslated in your userid or password, as this could be the cause of the 401 error.

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Tue Feb 24, 2026 9:56 am
by kwengert
Your comment about converting the EBCIDIC to UTF-8 pointed out something that I checked. This client has a System Value for QCCSID of 65535. My other customers have a QCCSID value of 37. I added a CLLE wrapper to my RPGLE that gets the current job CCSID, changes the current job's CCSID to 37, calls the RPGLE to create the json payload and send it, then sets the job CCSID back to the original value. I had my fingers crossed but that didn't work.

Could the fact that the system value is different cause the issue even though I changed the value on the job?

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Tue Feb 24, 2026 6:49 pm
by cdougherty
I had this problem!

So when transmitting the basic username/password combination I had that very same issue. I did some probably overcomplication but I did see that there were options to set a local and network ccsid:

rc = http_setOption('local-ccsid': '37');
rc = http_setOption('network-ccsid': '1208');

But as that still didn't work when I tried passing the username and password I finally did:

Dcl-S PassWd Char(100) CCSID(1208);
Dcl-S UserNm Char(100) CCSID(1208);

Because the differences in CCSIDs did do some things on conversions. This let me finally basic auth.

Re: Problem with Basic Authentication in HTTPAPI v1.53

Posted: Wed Feb 25, 2026 2:00 am
by kwengert
cdougherty wrote: Tue Feb 24, 2026 6:49 pm I had this problem!

So when transmitting the basic username/password combination I had that very same issue. I did some probably overcomplication but I did see that there were options to set a local and network ccsid:

rc = http_setOption('local-ccsid': '37');
rc = http_setOption('network-ccsid': '1208');

But as that still didn't work when I tried passing the username and password I finally did:

Dcl-S PassWd Char(100) CCSID(1208);
Dcl-S UserNm Char(100) CCSID(1208);

Because the differences in CCSIDs did do some things on conversions. This let me finally basic auth.
Thanks for the reply but, unfortunately, it didn't work for me.