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

问题:

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?

回答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

回答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:  [phone] 
OrgAbuseEmail:  [e-mail]
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN

OrgTechHandle: ZG39-ARIN
OrgTechName:   Google Inc
OrgTechPhone:  [phone] 
OrgTechEmail:  [e-mail]
OrgTechRef:    https://whois.arin.net/rest/poc/ZG39-ARIN

回答3:

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.

回答4:

I'm seeing lots of these requests (both with and without the .well-known subdirectory). They come from google-bot, but I suppose other spiders might start looking for them, too, at some point. Since my site doesn't have any overlapping functionality with any iOS (or Android) app, they are a waste of bandwidth. I like @aramisbear's answer to protect my application server (https://stackoverflow.com/a/36185061/467590). But I'm going to try adding them to my robots.txt instead. Since google-bot respects robots.txt (and other bots interested in creating app indexes almost certainly would, too) I would assume that doing this will prevent wasting even my nginx proxy's bandwidth, too.