> 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

Reply via email to