Task <***>.<3> request https://URL is NOT allowed to set HSTS for main doc (null)

I’d like to clarify the relationships here. It seems that you’re building an SDK, and one your SDKs clients is reporting this error. Is that right?

What API is your SDK using for these network requests? URLSession? Or perhaps you’re seeing it from a web view? Or something else?

On the reproducibility front, you wrote:

According to the client it happens only on Vision Pro.

All Vision Pros [1]? Or just one?

Is it happening on all networks? Or do they see different behaviour if they move to a different network (home to work, or work to home, or at the local coffee shop, or whatever).

Do you have a Vision Pro to try this on? If not, have you tried it in the simulator?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Or is that Visions Pro (-: I’ll have to look up the style guide!

Hi Sorry for late response:

I’d like to clarify the relationships here. It seems that you’re building an SDK, and one your SDKs clients is reporting this error. Is that right?

Correct

We use NSUrlSession Yes we have tried on simulator (wifi connection) but not on real one Vision Pro as we dont have one.

We have asked our customer about the network

Does your SDK always talk to your servers? Or can the client configure it to talk to some other server?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

The SDK talks to a server if the client has a proxy they can redirect by supplying a different url to the SDK. lets us check it

lets us check it

I don’t understand this. Can you elaborate on what you mean here?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Sorry, I wanted to see if by using proxy we will see the same behavior. So I manage to reproduce it on simulator, without proxy (BUT there is no crash as customer claims) I just see logs of the following:

Task <D8BF79FA-F57A-47D8-B491-5A008B69318A>.<2> request https://URL is NOT allowed to set HSTS for main doc (null) Ignoring alt-svc clear Task <D8BF79FA-F57A-47D8-B491-5A008B69318A>.<2> response ended Task <D8BF79FA-F57A-47D8-B491-5A008B69318A>.<2> finished successfully but the request was successful? so should we ignore that log?

so should we ignore that log?

Well, yes and no (-:

You putting that the log message in code style caused me to take a second look it it. The key item is this: for main doc (null). This makes it clear that the reason why the HSTS header was ineffective is that there’s no main document. A main document is very much a web browser thing, so CFNetwork ignores the HSTS header if there is none.

If you really want HSTS to stick, you could set a main document using the mainDocumentURL property. Whether you should or not is gonna depend on the context. For example:

• If you’re absolutely committed to HSTS, it’s probably better to just get your server on to the preload list [1].

• OTOH, HSTS is generally irrelevant for API calls because your SDK can ensure that all requests are HTTPS rather than HTTP. And ATS enforces that (unless the app opts out).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] https://hstspreload.org

I am not sure I fully understand ALL our requests are with HTTPS. So why would HSTS be relevant at all. We see that log ONLY on visionOS. (sorry if misunderstood something )

This is HSTS working opportunistically. I believe this is how things pan out:

1. You make a request.

2. The response includes an HSTS header.

3. CFNetwork tries to ingest that.

4. That ingestion fails because there’s no main document.

That failure has no impact on your app at all.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"