CD
Cloudflare Developers•3w ago
danst

'content-type' header issue when validating ApplePay Well Known Association file in Pages instance

Hi there, I've been directed here from CloudFlare Support. I have an Apple Well Known verification file saved in my Pages application: https://checkouttemp-dev.shopthru.dev/.well-known/apple-developer-merchantid-domain-association For the Pages project shopthru-checkout-dev.pages.dev which has the latest Production deployment of https://454ea75a.shopthru-checkout-dev.pages.dev. Account ID: c18d716869a1d1fb1b4d36b576f6929c The file can be loaded via a browser and a curl -I https://checkouttemp-dev.shopthru.dev/.well-known/apple-developer-merchantid-domain-association responds as expected (well, I think). However when I use this tool to validate the file (enter checkouttemp-dev.shopthru.dev as the Domain): https://branch.io/resources/aasa-validator/ It shows a validation error of: "Your file's 'content-type' header was not found or was not recognized." I have been trying things like setting the correct headers in a _headers file for this project: 
/.well-known/apple-developer-merchantid-domain-association
Content-Type: text/plain; charset=utf-8
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
ETag: ""
Accept-Ranges: bytes
/.well-known/apple-developer-merchantid-domain-association
Content-Type: text/plain; charset=utf-8
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
ETag: ""
Accept-Ranges: bytes
But to no avail. I believe there's something intrinsic about Pages going on here? - This issue is present whether or not I use the default domain (shopthru-checkout-dev.pages.dev) or the custom domain (checkouttemp-dev.shopthru.dev). - This validation error is occurring with known good files Association files as well. - This validation passes when run against the same field served from Google Cloud in a side experiment. Are there any known issues with Pages and Apple Well Known files around headers etc? Thanks
5 Replies
Hard@Work
Hard@Work•3w ago
I'm not too proficient with what the Content-Type is supposed to be for Apple's verification system, but I don't think text/plain is it
danst
danstOP•3w ago
According to the docs it is yeh. If I run this working example through the online validator tool (link above): host.checkout.shopthruapp.com It passes validation. A curl -I of: 
curl -I https://host.checkout.shopthruapp.com/.well-known/apple-developer-merchantid-domain-association
curl -I https://host.checkout.shopthruapp.com/.well-known/apple-developer-merchantid-domain-association
Returns: 
HTTP/2 200
cache-control: max-age=0
content-type: text/plain
function-execution-id: 6ndsqzt5h0gb
server: Google Frontend
strict-transport-security: max-age=31556926
x-cloud-trace-context: b07d71f7c20b90e2ef55ebfb03865147;o=1
x-country-code: GB
accept-ranges: bytes
date: Mon, 17 Mar 2025 
18:27:32 GMT
x-served-by: cache-ams21072-AMS
x-cache: MISS
x-cache-hits: 0
x-timer: S1742236052.990328,VS0,VE344
vary: cookie,need-authorization, x-fh-requested-host, accept-encoding
alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
content-length: 9098
HTTP/2 200
cache-control: max-age=0
content-type: text/plain
function-execution-id: 6ndsqzt5h0gb
server: Google Frontend
strict-transport-security: max-age=31556926
x-cloud-trace-context: b07d71f7c20b90e2ef55ebfb03865147;o=1
x-country-code: GB
accept-ranges: bytes
date: Mon, 17 Mar 2025 
18:27:32 GMT
x-served-by: cache-ams21072-AMS
x-cache: MISS
x-cache-hits: 0
x-timer: S1742236052.990328,VS0,VE344
vary: cookie,need-authorization, x-fh-requested-host, accept-encoding
alt-svc: h3=":443";ma=86400,h3-29=":443";ma=86400,h3-27=":443";ma=86400
content-length: 9098
This example has DNS running through Google Compute and Google Cloud Storage bucket, not CloudFlare pages.
Hard@Work
Hard@Work•3w ago
Maybe it's the charset breaking it?
danst
danstOP•3w ago
Removing that, so headers are: 
HTTP/2 200
date: Mon, 17 Mar 2025 19:40:28 GMT
content-type: text/plain
cf-cache-status: DYNAMIC
function-execution-id: u4a8pq4bcvj7
x-cloud-trace-context: 31ab72826dc1febc6183ab0130419d6f;o=1
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=NAZB70gePSDsJQjYOsTB2lwg3MC9QlFmA%2FWHZu9NnRNyd387SghB%2FrxaACCjJF1rwv9tJ3HA3Hk4do%2BXVwygRqu%2FY6xZXcg%2B9fvZx1KpBkeoLbzSgeAVjbnuH%2BakZU7LG8pKVAywcU%2F3LlW0svOxU2pR4oaXZvWYBICG"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
vary: Accept-Encoding
server: cloudflare
cf-ray: 921ef64ac8b49551-LHR
server-timing: cfL4;desc="?proto=TCP&rtt=18651&min_rtt=16359&rtt_var=6376&sent=6&recv=10&lost=0&retrans=0&sent_bytes=2946&recv_bytes=673&delivery_rate=177027&cwnd=252&unsent_bytes=0&cid=28cc679627f46f25&ts=2064&x=0"
HTTP/2 200
date: Mon, 17 Mar 2025 19:40:28 GMT
content-type: text/plain
cf-cache-status: DYNAMIC
function-execution-id: u4a8pq4bcvj7
x-cloud-trace-context: 31ab72826dc1febc6183ab0130419d6f;o=1
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=NAZB70gePSDsJQjYOsTB2lwg3MC9QlFmA%2FWHZu9NnRNyd387SghB%2FrxaACCjJF1rwv9tJ3HA3Hk4do%2BXVwygRqu%2FY6xZXcg%2B9fvZx1KpBkeoLbzSgeAVjbnuH%2BakZU7LG8pKVAywcU%2F3LlW0svOxU2pR4oaXZvWYBICG"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
vary: Accept-Encoding
server: cloudflare
cf-ray: 921ef64ac8b49551-LHR
server-timing: cfL4;desc="?proto=TCP&rtt=18651&min_rtt=16359&rtt_var=6376&sent=6&recv=10&lost=0&retrans=0&sent_bytes=2946&recv_bytes=673&delivery_rate=177027&cwnd=252&unsent_bytes=0&cid=28cc679627f46f25&ts=2064&x=0"
Makes no difference. I feel it's something fundamental to Pages or something staggeringly obvious.
danst
danstOP•2w ago
It seems like this was a red herring at least in terms of our implementation requirement. I'm still not sure why that validation issue is happening but am going to suggest that this issue may to some extent be crossing over in to areasof the third party vendor (i.e. the https://branch.io/resources/aasa-validator/ application). Therefore am closing.
AASA Validator | Branch
Branch’s Universal Links Validator analyzes your site to check if your apple-app-site-association is properly hosted for Universal Links.

Did you find this page helpful?