Post

Replies

Boosts

Views

Activity

AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
2
1
95
14h
AASA CDN intermittently times out / requests wrong path (/apple-app-site-association vs /.well-known/...)
Hi Everyone, We are tinkering on an App using associated domains with the working name "uff2.de". We have configured our Webserver (Caddy) to restrict all URIs except for /.well-known/apple-app-site-association using Www-Authenticate. Recently our associated domains started becoming flaky, which we believe has to do with requests from Apple’s CDN failing: The following example uses a query string to trigger a fresh request by Apple’s CDN. curl -sD - "https://app-site-association.cdn-apple.com/a/v1/uff2.de?foobar" -o /dev/null HTTP/1.1 404 Not Found Server: AppleHttpServer/7b3d349ae60c243cdd677edbde3e93e460f75820 Date: Sat, 05 Sep 2026 12:01:16 GMT Content-Type: text/plain; charset=utf-8 Content-Length: 10 Apple-Failure-Details: {"cause":"Connection timed out"} Apple-Failure-Reason: SWCERR00301 Timeout Apple-From: https://uff2.de/.well-known/apple-app-site-association Apple-Try-Direct: true Cache-Control: max-age=3600,public Vary: Accept-Encoding X-B3-TraceId: 457b6172513a930f Strict-Transport-Security: max-age=31536000 Age: 32 Via: https/1.1 defra2-vp-vst-018.ts.apple.com (acdn/331.16659), https/1.1 defra2-vp-vfe-016.ts.apple.com (acdn/331.16659), https/1.1 gbslo5-xdc-mx-020.ts.apple.com (acdn/331.16659), https/1.1 uklon5-edge-fx-024.ts.apple.com (acdn/331.16659) X-Cache: miss, miss, miss, miss CDNUUID: df5ac203-4188-4722-8bbc-68e9d9fd0b33-1118024500 Connection: keep-alive To investigate this further we enabled access logging and are seeing the following request that is blocked by us: 2026/09/05 12:01:16.824 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.82.202", "remote_port": "48366", "client_ip": "57.103.82.202", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000083782, "size": 0, "status": 401, "resp_headers": {"Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Www-Authenticate": ["Basic realm=\"restricted\""]}} But this seems to be the wrong URI (/apple-app-site-association instead of /.well-known/apple-app-site-association). When swapping ?foobar for other query strings like ?foobar2 or ?foobar3, some requests randomly work and some don’t. We’re also seeing flakiness for the same path (both with and without a query string) across time, but this is harder to test due to caching. For reference this is a correct request: 2026/09/05 17:54:26.075 INFO http.log.access.log0 handled request {"request": {"remote_ip": "57.103.81.17", "remote_port": "8692", "client_ip": "57.103.81.17", "proto": "HTTP/1.1", "method": "GET", "host": "uff2.de", "uri": "/.well-known/apple-app-site-association", "headers": {"User-Agent": ["AASA-Bot/1.0.0"], "Accept-Encoding": ["gzip"]}, "tls": {"resumed": false, "version": 772, "cipher_suite": 4865, "proto": "", "server_name": "uff2.de"}}, "bytes_read": 0, "user_id": "", "duration": 0.000088472, "size": 469, "status": 200, "resp_headers": {"Accept-Ranges": ["bytes"], "Content-Length": ["469"], "Server": ["Caddy"], "Alt-Svc": ["h3=\":443\"; ma=2592000"], "Vary": ["Accept-Encoding"], "Etag": ["\"dgrdbiykgv3ad1\""], "Content-Type": [], "Last-Modified": ["Sun, 01 Mar 2026 10:19:41 GMT"]}} Did we misread the documentation and should also serve /apple-app-site-association? Why would requests sometimes be made to /.well-known/apple-app-site-association and sometimes to /apple-app-site-association? Thank you!
Replies
2
Boosts
1
Views
95
Activity
14h