Requests to /.well-known/apple-app-site-association

I just checked my server logs and found the following weird requests coming in quite a lot. I have iOS 9 Universal Linking implemented, but those requests are running against /apple-app-site-association as far as I know.

Jan 15 09:36:23 method=GET path="/.well-known/apple-app-site-association"

Has anyone else seen these patterns? Is this some known spamming or something?

Solution 1:

i believe iOS 9.3 introduced slightly different lookup logic around the apple-app-site-association file and the app handoff feature.

"Handoff first searches for the file in the .well-known subdirectory (for example, https://example.com/.well-known/apple-app-site-association), falling back to the top-level domain if you don’t use the .well-known subdirectory."

see: https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10

Solution 2:

I also received the following in my log:

[Mon Feb 29 12:34:53 2016] [error] [source 66.249.75.XXX] File does not exist: /public_path/apple-app-site-association

Where XXX in the log is a number between 0 to 255.

Then, I checked Whois IP 66.249.69.0, 1, 2 ....... 255

And what I found, All IP in range from 66.249.64.0 - 66.249.95.255 assigned to Google Inc. Wait are you kidding me, why google requesting apple-app-site-association on my server?

Because Google extending it's mapping to include information on associations between websites and specific iOS apps for Google App Indexing for universal links from Google Search in Safari..

Whois log for IP 66.249.64.0

NetRange:       66.249.64.0 - 66.249.95.255
CIDR:           66.249.64.0/19
NetName:        GOOGLE
NetHandle:      NET-66-249-64-0-1
Parent:         NET66 (NET-66-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       
Organization:   Google Inc. (GOGL)
RegDate:        2004-03-05
Updated:        2012-02-24
Ref:            https://whois.arin.net/rest/net/NET-66-249-64-0-1



OrgName:        Google Inc.
OrgId:          GOGL
Address:        1600 Amphitheatre Parkway
City:           Mountain View
StateProv:      CA
PostalCode:     94043
Country:        US
RegDate:        2000-03-30
Updated:        2015-11-06
Ref:            https://whois.arin.net/rest/org/GOGL


OrgAbuseHandle: ABUSE5250-ARIN
OrgAbuseName:   Abuse
OrgAbusePhone:  +1-650-253-0000 
OrgAbuseEmail:  [email protected]
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN

OrgTechHandle: ZG39-ARIN
OrgTechName:   Google Inc
OrgTechPhone:  +1-650-253-0000 
OrgTechEmail:  [email protected]
OrgTechRef:    https://whois.arin.net/rest/poc/ZG39-ARIN

Solution 3:

Since iOS 9.3 Apple will first try to download /.well-known/apple-app-site-association and in case it fails it fallbacks to /apple-app-site-association.

See Apple's Technical Q&A QA1919:

Incoming requests for /.well-known/apple-app-site-association file

Q: Why is my web server receiving requests for https://example.com/.well-known/apple-app-site-association?

A: The recently released iOS 9.3 update implements RFC 5785. Because of this, devices running iOS 9.3 will first request /.well-known/apple-app-site-association for the apple-app-site-association file that is required to implement Universal Links and Shared Web Credentials. If the file is not found in this location, then the device will request the file in the root of the web server, as with prior releases of iOS 9.

Solution 4:

We're seeing this behavior as well. The vast majority of our server's access log files are now requests for this particular file.

If you happen to be running a setup with nginx serving static files in front of an application server / framework, be sure to verify that the /.well-known/apple-app-site-association AND /apple-app-site-association files either exist or return a response.

If they don't, the missing requests will all be passed along to your framework, which in many cases results in having to process your routes before determining that there is no match. Until we made that change yesterday, the added stress to our servers was fairly significant.