Worker fails to trigger on one domain but not another

dash-crypto
#1

Hi all,

Very new to Workers and Cloudflare in general, please bear with me.

We’re trying to use Cloudflare Workers for a reverse proxy per the instructions here:

  • Currently, our assets are hosted at assets.[MAIN_DOMAIN].com. We want to reverse proxy them from [MAIN_DOMAIN].com/images/*.

  • We have two domains: prod [MAIN_DOMAIN].com and dev [MAIN_DOMAIN]dev.com.

I re-worked the code from the above tutorial, and it’s working fine. It generates the appropriate link and displays the appropriate reverse proxy behavior on our dev site, but not on our prod site. I don’t understand why.

This is the route that is working on our dev site: ROOT/images/WILDCARD

This is the route that is not working on our prod site: WILDCARD.ROOT/images/WILDCARD

I have also tried using the same route on prod as on dev, but thought that the prepended wild card might help based on this topic:

We seem to have the same problem, but I don’t know what steps to take based on the OP’s stated solution:

Would appreciate any input. Don’t really know where to start in terms of debugging this.

The basic issue is that the routes above are not triggering the Worker.

#2

Well the worker below works for us but we cannot use the free TLS certs and instead on the “Crypto” tab will select “Full” for the “SSL” section and buy “Dedicated” “Edge Certificates”

addEventListener(‘fetch’, event => {

event.respondWith(handleRequest(event.request))

})

/**

  • Fetch and log a request

  • @param {Request} request

*/

async function handleRequest(request) {

// console.log(‘Got request’, request)

// const response = await fetch(request)

// console.log(‘Got response’, response)

// return response

const incomingUrl = new URL(request.url);

console.log(incomingUrl: ${incomingUrl})

let targetUrl

switch (incomingUrl.hostname) {

case ‘document.dev.localcover.net’:

targetUrl = [https://lc-api-document-nt6xmb7pqq-uc.a.run.app](https://lc-api-document-nt6xmb7pqq-uc.a.run.app)${incomingUrl.pathname}${incomingUrl.search}

break

case ‘document.uat.localcover.net’:

targetUrl = [https://lc-api-document-uuqmg4m3jq-uc.a.run.app](https://lc-api-document-uuqmg4m3jq-uc.a.run.app)${incomingUrl.pathname}${incomingUrl.search}

break

case ‘document.prd.localcover.net’:

targetUrl = [https://lc-api-document-gpgpu6w6uq-uc.a.run.app](https://lc-api-document-gpgpu6w6uq-uc.a.run.app)${incomingUrl.pathname}${incomingUrl.search}

break

default:

targetUrl = incomingUrl

}

console.log(Invoking: ${targetUrl} with incoming request)

const response = await fetch(targetUrl, {

method: request.method,

body: request.body,

headers: request.headers

})

return response

}

devops6

    March 12

Hi all,

Very new to Workers and Cloudflare in general, please bear with me.

We’re trying to use Cloudflare Workers for a reverse proxy per the instructions here:

  [The Cloudflare Blog – 15 Feb 19](https://blog.cloudflare.com/subdomains-vs-subdirectories-improved-seo-part-2/)

Subdomain vs. Subdirectory Strategies – Improving SEO Pt 2

In Part 1, the merits and tradeoffs of subdirectories and subdomains were discussed. The subdirectory strategy is typically superior to subdomains because subdomains suffer from keyword and backlink dilution.

  • Currently, our assets are hosted at assets.[MAIN_DOMAIN].com. We want to reverse proxy them from [MAIN_DOMAIN].com/images/*.
  • We have two domains: prod [MAIN_DOMAIN].com and dev [MAIN_DOMAIN]dev.com.

I re-worked the code from the above tutorial, and it’s working fine. It generates the appropriate link and displays the appropriate reverse proxy behavior on our dev site, but not on our prod site. I don’t understand why.

This is the route that is working on our dev site: ROOT/images/WILDCARD

This is the route that is not working on our prod site: WILDCARD.ROOT/images/WILDCARD

I have also tried using the same route on prod as on dev, but thought that the prepended wild card might help based on this topic:

[Worker OK in Preview but not from web](https://community.cloudflare.com/t/worker-ok-in-preview-but-not-from-web/45439) [Workers](https://community.cloudflare.com/c/developers/workers)

Hi, I have a worker which will intercept requests to an origin and return a response from a request to a different url. It works fine in preview and testing mode but when invoked from the web, the worker does not trigger and the origin response is displayed. I have configured this on records on two different domains with the same result. Both records are ‘orange’. Is there a switch somewhere that I need to flick to make the worker ‘live’? Thanks in advance for any help

We seem to have the same problem, but I don’t know what steps to take based on the OP’s stated solution:

Worker OK in Preview but not from web
the issue was that the free certificate from CloudFlare does not support multi-level domains, I needed to buy a multi-level cert for $10 per month from ‘Crypto/Edge Certificates’

Would appreciate any input. Don’t really know where to start in terms of debugging this.

The basic issue is that the routes above are not triggering the Worker.


Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

Attention:

The information contained in this
message and or attachments is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material.
Any review, retransmission, dissemination or other use of, or taking of any
action in reliance upon this information by persons or entities other than the
intended recipient is prohibited. If you received this in error please contact
the sender and delete the material from any system and destroy any copies.

Thank You.

#3

Thanks for the quick reply. I’ve confirmed we have those certs and it still doesn’t seem to work. Could you share what your routing looks like?

#4

RESOLVED: As of 03/21/2019 (and a little earlier), Shopify sites no longer have access to features like reverse proxy. Confirmed with support.

1 Like