ios 对 /.well-known/apple-app-site-association 的请求
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/34812135/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Requests to /.well-known/apple-app-site-association
提问by Tim Specht
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.
我刚刚检查了我的服务器日志，发现有很多以下奇怪的请求。我已经实现了 iOS 9 通用链接，但据我所知，这些请求是针对 /apple-app-site-association 运行的。
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?
有没有其他人见过这些图案？这是一些已知的垃圾邮件还是什么？
采纳答案by busticated
i believe iOS 9.3 introduced slightly different lookup logic around the apple-app-site-association file and the app handoff feature.
我相信 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."
“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
回答by Vineet Choudhary
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 XXXin the log is a number between 0 to 255.
凡XXX在日志中是介于0到255之间的数字。
Then, I checked Whois IP 66.249.69.0, 1, 2....... 255
然后，我检查了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.255assigned to Google Inc. Wait are you kidding me, why google requesting apple-app-site-associationon my server?
我发现，从66.249.64.0- 66.249.95.255范围内的所有 IP分配给Google Inc. 等等，你在开玩笑apple-app-site-association吗，为什么谷歌在我的服务器上请求？
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..
因为 Google 扩展了它的映射，以包含有关网站和特定 iOS 应用程序之间关联的信息，用于Google App Indexing 以获取来自 Safari 中 Google 搜索的通用链接。.
Whois log for IP 66.249.64.0
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 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
回答by brightball
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-associationAND /apple-app-site-associationfiles either exist or return a response.
如果您碰巧在应用程序服务器/框架前使用 nginx 服务静态文件运行设置，请务必验证/.well-known/apple-app-site-associationAND/apple-app-site-association文件是否存在或返回响应。
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.
如果他们不这样做，丢失的请求将全部传递给您的框架，这在许多情况下导致必须在确定没有匹配之前处理您的路由。在我们昨天做出改变之前，给我们的服务器增加的压力是相当大的。
回答by sootsnoot
I'm seeing lots of these requests (both with and without the .well-knownsubdirectory). 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.txtinstead. Since google-botrespects 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 nginxproxy's bandwidth, too.
我看到很多这样的请求（有和没有.well-known子目录）。它们来自google-bot，但我想其他蜘蛛也可能会在某个时候开始寻找它们。由于我的网站没有与任何iOS（或Android）应用程序重叠的功能，因此它们浪费了带宽。我喜欢@aramisbear 的回答来保护我的应用程序服务器 ( https://stackoverflow.com/a/36185061/467590)。但我将尝试将它们添加到我的robots.txt。由于google-bot尊重robots.txt（以及其他对创建应用程序索引感兴趣的机器人几乎肯定也会），我认为这样做也可以防止浪费我的nginx代理带宽。
回答by Marián ?erny
Since iOS 9.3 Apple will first try to download /.well-known/apple-app-site-associationand in case it fails it fallbacks to /apple-app-site-association.
由于 iOS 9.3 Apple 将首先尝试下载/.well-known/apple-app-site-association，如果失败，它会回退到/apple-app-site-association.
See Apple's Technical Q&A QA1919:
请参阅 Apple 的技术问答 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-associationfor theapple-app-site-associationfile that is required to implement Universal Linksand 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.
对 /.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 的先前版本一样。
