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

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

我刚刚检查了我的服务器日志,发现以下奇怪的请求非常多。我已经实施了 iOS 9 个通用链接,但据我所知,这些请求是 运行 针对 /apple-app-site-association 的。

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

还有其他人见过这些图案吗?这是一些已知的垃圾邮件吗?

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

[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之间的数字。

然后,我检查了Whois IP 66.249.69.0, 1, 2 ....... 255

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

因为 Google 扩展它的映射以包含网站与 Google App Indexing for universal links from Google Search in Safari. 的特定 iOS 应用之间的关联信息。

IP 66.249.64.0 的 Whois 日志

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

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

"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."

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

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

如果您碰巧 运行 在应用程序服务器/框架前面设置了 nginx 服务静态文件,请务必验证 /.well-known/apple-app-site-association/apple-app-site-association 文件存在或 return 回复。

如果他们不这样做,丢失的请求将全部传递到您的框架,这在许多情况下导致必须在确定没有匹配之前处理您的路由。在我们昨天做出更改之前,给我们的服务器增加的压力相当大。

我看到很多这样的请求(有和没有 .well-known 子目录)。它们来自 google-bot,但我想其他蜘蛛也可能在某个时候开始寻找它们。由于我的站点与任何 iOS(或 Android)应用程序没有任何重叠功能,因此它们是对带宽的浪费。我喜欢@aramisbear 保护我的应用程序服务器的回答 ()。但我会尝试将它们添加到我的 robots.txt 中。由于 google-bot 尊重 robots.txt(其他对创建应用程序索引感兴趣的机器人几乎肯定也会这样做)我认为这样做甚至可以防止浪费我的 nginx 代理的带宽。

自 iOS 9.3 Apple 将首先尝试下载 /.well-known/apple-app-site-association,如果失败则回退到 /apple-app-site-association

查看 Apple 的 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.