请求/.well-known/apple-app-site-association

Question

我刚检查了我的服务器日志,发现以下奇怪的请求进入了很多.我实现了iOS 9 Universal Linking,但据我所知,这些请求是针对/ apple-app-site-association运行的.

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

还有其他人看过这些模式吗？这是一些已知的垃圾邮件还是什么？

Answer 1

我相信iOS 9.3围绕apple-app-site-association文件和app切换功能引入了略微不同的查找逻辑.

"切换首先在.well-known子目录中搜索该文件(例如,https: //example.com/.well-known/apple-app-site-association ),如果你回到顶级域名不要使用.well-known子目录."

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

Answer 2

我还在我的日志中收到以下内容:

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

凡XXX在日志中是介于0到255之间的数字.

然后,我查域名注册IP 66.249.69.0,1,2 ....... 255

我发现,所有IP的范围从66.249.64.0 - 66.249.95.255分配到Google Inc.等等,你在开玩笑吧,为什么google apple-app-site-association在我的服务器上请求？

因为Google扩展了它的映射,以包含有关网站与特定iOS应用之间关联的信息,以便通过Safari中的Google搜索获取Google App Indexing for universal链接..

Whois登录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@google.com
OrgAbuseRef:    https://whois.arin.net/rest/poc/ABUSE5250-ARIN

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

Answer 3

由于 iOS 9.3 Apple 将首先尝试下载/.well-known/apple-app-site-association，如果失败，它会回退到/apple-app-site-association.

请参阅 Apple 的技术问答 QA1919：

对 /.well-known/apple-app-site-association 文件的传入请求

问：为什么我的网络服务器会收到https://example.com/.well-known/apple-app-site-association 的请求？

A：最近发布的 iOS 9.3 更新实现了RFC 5785。因此，运行 iOS 9.3 的设备将首先请求实现Universal Links和Shared Web Credentials所需/.well-known/apple-app-site-association的apple-app-site-association文件。如果在此位置找不到该文件，则设备将在 Web 服务器的根目录中请求该文件，就像 iOS 9 的先前版本一样。

Answer 4

我们也看到了这种行为.我们服务器的绝大多数访问日志文件现在都是对此特定文件的请求.

如果您正在运行使用nginx在应用程序服务器/框架前提供静态文件的安装程序,请确保验证/.well-known/apple-app-site-associationAND /apple-app-site-association文件是否存在或返回响应.

如果他们不这样做,那么缺失的请求将全部传递给您的框架,这在许多情况下导致必须在确定没有匹配之前处理您的路由.在我们昨天做出改变之前,对我们服务器的额外压力是相当大的.