62

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

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

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

4

5 回答 5

38

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

“Handoff 首先在 .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

于 2016-03-22T16:48:02.020 回答
13

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

[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.255的所有 IP分配给Google Inc. 等等，你在开玩笑吧，为什么谷歌apple-app-site-association在我的服务器上请求？

因为谷歌扩展了它的映射，包括网站和特定 iOS 应用程序之间的关联信息，用于谷歌应用索引，用于 Safari 中谷歌搜索的通用链接。.

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
于 2016-03-05T08:44:49.980 回答
6

由于 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的请求？

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

于 2019-03-15T10:46:22.573 回答
5

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

如果您碰巧在应用程序服务器/框架前面运行 nginx 服务静态文件的设置，请务必验证/.well-known/apple-app-site-associationAND/apple-app-site-association文件是否存在或返回响应。

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

于 2016-03-23T17:38:06.940 回答
3

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

于 2016-11-06T17:51:48.910 回答