well test links link known from domains associated ios ios-universal-links

ios - test - Solicitudes para/.well-known/apple-app-site-association



universal links ios (5)

Acabo de revisar los registros de mi servidor y encontré que las siguientes solicitudes raras llegan bastante. Tengo implementado el enlace universal iOS 9, pero esas solicitudes se están ejecutando contra / apple-app-site-association hasta donde yo sé.

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

¿Alguien más ha visto estos patrones? ¿Es esto algún spam conocido o algo así?


Creo que iOS 9.3 introdujo una lógica de búsqueda ligeramente diferente alrededor del archivo apple-app-site-association y la función de transferencia de aplicaciones.

"Handoff primero busca el archivo en el subdirectorio .well conocido (por ejemplo, https://example.com/.well-known/apple-app-site-association ), volviendo al dominio de nivel superior si no use el subdirectorio bien conocido ".

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


Desde iOS 9.3, Apple primero intentará descargar /.well-known/apple-app-site-association y, en caso de que falle, retrocede a /apple-app-site-association .

Consulte las preguntas y respuestas técnicas de Apple QA1919 :

Solicitudes entrantes para /.well-known/apple-app-site-association file

P: ¿Por qué mi servidor web recibe solicitudes de https://example.com/.well-known/apple-app-site-association ?

R: La actualización iOS 9.3 recientemente lanzada implementa RFC 5785 . Debido a esto, los dispositivos que ejecutan iOS 9.3 primero solicitarán /.well-known/apple-app-site-association para el archivo de apple-app-site-association que se requiere para implementar enlaces universales y credenciales web compartidas . Si el archivo no se encuentra en esta ubicación, el dispositivo solicitará el archivo en la raíz del servidor web, como en las versiones anteriores de iOS 9.


Estoy viendo muchas de estas solicitudes (con y sin el subdirectorio .well-known ). Vienen de google-bot , pero supongo que otras arañas podrían comenzar a buscarlos también, en algún momento. Dado que mi sitio no tiene ninguna funcionalidad superpuesta con ninguna aplicación de iOS (o Android ), son una pérdida de ancho de banda. Me gusta la respuesta de @ aramisbear para proteger mi servidor de aplicaciones ( https://.com/a/36185061/467590 ). Pero voy a intentar agregarlos a mi robots.txt lugar. Dado que google-bot respeta el robots.txt (y otros bots interesados ​​en crear índices de aplicaciones seguramente también lo harían), supongo que al hacer esto también evitaré desperdiciar el ancho de banda de mi proxy nginx .


También estamos viendo este comportamiento. La gran mayoría de los archivos de registro de acceso de nuestro servidor ahora son solicitudes de este archivo en particular.

Si está ejecutando una configuración con nginx que sirve archivos estáticos frente a un servidor / marco de aplicaciones, asegúrese de verificar que /.well-known/apple-app-site-association AND /apple-app-site-association los archivos existen o devuelven una respuesta.

Si no lo hacen, las solicitudes que faltan se pasarán a su marco, lo que en muchos casos tiene que procesar sus rutas antes de determinar que no hay coincidencia. Hasta que hicimos ese cambio ayer, el estrés agregado a nuestros servidores fue bastante significativo.


También recibí lo siguiente en mi registro:

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

Donde XXX en el registro es un número entre 0 y 255.

Luego, verifiqué Whois IP 66.249.69.0 , 1 , 2 ....... 255

Y lo que encontré, todas las IP en el rango de 66.249.64.0 - 255 asignadas a Google Inc Espera, ¿estás bromeando? ¿Por qué Google solicita la apple-app-site-association en mi servidor?

Debido a que Google extiende su mapeo para incluir información sobre asociaciones entre sitios web y aplicaciones específicas de iOS para Google App Indexing para enlaces universales de Búsqueda de Google en Safari. .

Registro Whois para 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 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