Hi @Dicky019,
TL;DR;
I can honestly say, it would really surprise me if this were somehow an SDK issue. It seems very unlikely to me. Not impossible, but it'd just surprise me.
All the details...
Definitely not intentional and I really doubt it's the SDK that has any effect. At the end of the day both the sdk's and the tunneler will do nothing more than send the bytes it was told to send. You show "Set-Cookie:" in the sdk example (I think you're using Swift?) but it'll be more instructive to see the actual swift code. Don't take offfense, but my guess is that you just did it wrong via Swift somehow. (i mean this in the nicest way possible hehehe)
These are not OpenZiti related and any bearing is entirely up to your server and your client. OpenZiti is just a very secure bit-for-bit pipe from client to server. So whatever the client sends (or needs) is what is sent.
Unlikely to be http/https related. If you're successfully sending https (not having TLS issues like before), http/https is not relevant
None whatsoever. With OpenZiti's end-to-end encryption this sort of action by OpenZiti is actually impossible. (which is why e2ee is so nice for security)
*Sort of/maybe. I say "sort of" because it depends on the client being used. When you use a tunneler, the client will be some http client that knows all the http protocols/specs. If you send a websocket request, it'll upgrade to a websocket, if you send https, it'll handle setting up the TLS connection etc. So there are things these clients do, that are not done when you're setting up your OWN connections inside an SDK. So while it's not the OpenZiti SDK/tunneler related, it might (and tbh, probably is) related to how you're doing it in the swift sdk.
A great way to test this is to take OpenZiti out of the equation entirely, assuming you can use the same hostname/fqdn (this is one of those important details that are easy to miss). If you can do it without ziti, when you plug ziti into the mix it should behave identically. The only difference is you'll have end-to-end encryption and a zero trust mesh overlay routing traffic and have all the good stuff OpenZiti offers.
Another great way to test is by inspecting the actual HTTP request and response. I would highly encourage you to get that sort of protocol-level logging going in your app so that you can see the actual HTTP request being made by the SDK app. You coudl then compare that to the tunneler using a browser's dev tools or a curl -v.
If you are doing that and are still stumped, you could post a sample HTTP request/response. If something seems obvious, I/we might be able to help. For example, something like this (I used curl):
curl -sIv https://mattermost.tools.netfoundry.io:443
* Host mattermost.tools.netfoundry.io:443 was resolved.
* IPv6: (none)
* IPv4: 100.100.0.13
* Trying 100.100.0.13:443...
* Connected to mattermost.tools.netfoundry.io (100.100.0.13) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /usr/ssl/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / secp256r1 / rsaEncryption
* ALPN: server accepted h2
* Server certificate:
* subject: CN=tools.netfoundry.io
* start date: Apr 20 00:00:00 2025 GMT
* expire date: May 19 23:59:59 2026 GMT
* subjectAltName: host "mattermost.tools.netfoundry.io" matched cert's "*.tools.netfoundry.io"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M03
* SSL certificate verify ok.
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://mattermost.tools.netfoundry.io:443/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: mattermost.tools.netfoundry.io]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.9.0]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: mattermost.tools.netfoundry.io
> User-Agent: curl/8.9.0
> Accept: */*
>
* Request completely sent off
< HTTP/2 200
HTTP/2 200
< date: Thu, 12 Jun 2025 00:29:41 GMT
date: Thu, 12 Jun 2025 00:29:41 GMT
< content-type: text/html
content-type: text/html
< cache-control: no-cache, max-age=31556926, public
cache-control: no-cache, max-age=31556926, public
< content-security-policy: frame-ancestors 'self' ; script-src 'self' cdn.rudderlabs.com
content-security-policy: frame-ancestors 'self' ; script-src 'self' cdn.rudderlabs.com
< permissions-policy:
permissions-policy:
< referrer-policy: no-referrer
referrer-policy: no-referrer
< vary: Origin
vary: Origin
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< x-request-id: 5yahhdaee3fpbc4r7chfkhxmxh
x-request-id: 5yahhdaee3fpbc4r7chfkhxmxh
< x-version-id: 10.8.1.15129630706.fdbc54aba1e303dd2d4a2911de48b59a.true
x-version-id: 10.8.1.15129630706.fdbc54aba1e303dd2d4a2911de48b59a.true
<
* Connection #0 to host mattermost.tools.netfoundry.io left intact