Issues with .well-known Workerl

Developers Workers
1

We are trying to serve a worker to validate our domain for Apple pay under .well-known/apple-developer-merchantid-domain-association as per their instructions (https://stripe.com/docs/stripe-js/elements/payment-request-button#verifying-your-domain-with-apple-pay).

While the worker inside the debugger works, we are then met with Invalid .well-known request on the front-end.

I have a worker set up under the route [domain]/.well-known/apple-developer-merchantid-domain-association with the following settings;

export default {
  async fetch(request, env) {
    return await handleRequest(request)
  }
}

async function handleRequest(request) {
  return new Response(
    "[REDACTED]"
  )
}

For context we are serving our Website with Webflow which don’t allow folder / file hosting. This was the only way I can figure out how to do it. Any other suggestions welcome!

2

@thedaveCA I saw in another post you had this working but can’t message you privately.

3

No problem, happy to help out when I can!

That should work. I’m not great with workers so I wanted to test it out just in case I was missing/forgetting a step, so here is what I did.

  • Create a new worker → HTTP handler.
  • Hit Quick Edit and pasted your code.
  • Verified that it works in the Quick Edit HTTP/Preview so I hit Save and Deploy.
  • It can now be accessed at https://■■■■■■.■■.workers.dev/

Do you at least get that far? Any HTTPS GET request to the subdomain assigned to this worker should return the content.

This assumes your requests are going through a domain/hostname proxied by Cloudflare (:orange:), and that the existing response isn’t cached.

Also keep in mind any page rules, redirects, or other things that might be interfering along the way.

What do you get if you try curl?

curl --include [domain]/.well-known/apple-developer-merchantid-domain-association

You can use curl online via reqbin.com/curl if you don’t have the command line tool, just be sure to visit the Header or Raw tabs as the headers might provide some clues. In particular make sure that Server: cloudflare is shown,

The full response (for me) for either URI above looks like this:

HTTP/1.1 200 OK
Date: Mon, 14 Nov 2022 18:23:36 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 10
Connection: keep-alive
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=%2BWZYlJlA6E08ENAABQ9fQqTKl%2FMmpo1SlLRZ2gfbvxPFYA4KQDgfsylSHIb6pmPI%2FmBdJFiMfWwtk2GKw9XLzIeG9p4JxsKV1nbYbtFNaaIKe0Aq6%2FtqAlJ5tYk6GIFxTP4%2F1rqMm6IOXUs%3D"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 76a1c77c5cd8bf08-YYC
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

[REDACTED]

(Yes, I’m literally using [REDACTED], but assuming the string is something plain-text there shouldn’t be any differences. Also, I’ll probably edit out the URIs above when I delete the worker when this thread is resolved/closed).

2 Likes
4

Thank you for your time and detail in this response. I can get everything working up until adding my route.

After all that, I think it’s something to do with proxying through Cloudflare. Because of some Webflow nonsense we are set to DNS only which my guess is what’s causing the issues.

How does yours perform if switching to DNS only on that domain? (if you can)

5

In DNS-Only mode, you can’t use any Cloudflare features, such as Workers. All requests go direct to origin.

1 Like
6

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.