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

放肆的年华 提交于 2019-12-18 01:21:10

问题


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:  +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



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




回答5:


Since iOS 9.3 Apple will first try to download /.well-known/apple-app-site-association and in case it fails it fallbacks to /apple-app-site-association.

See Apple's 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.



来源:https://stackoverflow.com/questions/34812135/requests-to-well-known-apple-app-site-association

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!