> On Dec 5, 2017, at 3:12 AM, Quinn The Eskimo! <eski...@apple.com> wrote: > > I suspect B.2. is what’s going on here. That is, the HSTS entry has > rewritten your HTTP URL to HTTPS before it hits the wire, and thus it’s never > blocked by ATS.
Thank you, Quinn! I do think you must have pegged the answer. I was not familiar with HSTS but now that I’ve read up on it it matches the scenario nicely. Wordpress.com does indeed include a Strict-Transport-Security header in its responses. The only thing that eludes me is not being able to figure out how to prompt the system to cache the HSTS status for the second domain. It’s mostly an academic curiosity at this point, but it since I’ve been loading the second domain’s URLs in web views, across NSURLSession data tasks, etc., I might have expected by now that its HSTS status would be cached. > B.2. For those not on the list, if the client ever sees the HSTS header it > can cache that knowledge outside of the standard `NSURLCache`. Do you have any insights about logic the system uses when deciding whether to cache the information, and at which level of the frameworks it’s done? I’m guessing it would be at the CFNetwork layer. Do you think it might be a bug, or at least an opportunity for improvement, that the system is not caching my HSTS-compliant target (sub)domain? Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com