Worldpay callback URL cannot be SNI, but page rules not working

For reasons which Worldpay cannot answer, they cannot accept a redirect to a flexible ssl endpoint because of SNI. But they CAN accept a call-back to a non-ssl page. I know - insane!

So I thought the solution would be simple - for all the rest of the site, ssl, rewrite, redirects etc are on.

But I thought I could over-ride this by using a page rule for the callback page as per the image below.

Except, it just keeps switching between http and https with a browser message about “too many redirects”.
Where am I going wrong? Thanks!

When it happens the too many redirects error is usually due to the fact that either the origin or Cloudflare redirect to the opposite version continuously.

Have you disabled Always Use HTTPS on that path? Are you sure your origin isn’t forcing HTTPS or rejecting HTTP?

No, there was a Cloudlare plugin but that’s been disabled.

Yes, I have “always use https” and “https rewrites” set on the SSL/TLS app of the domain.

However, I want to use the pagerules to over-ride that.

Should I instead be using ONLY pagerules for this case? And if so… any pointers? Thanks!

Simply add a Always Use HTTPS turned to off on that page rule, it should fix the issue

“Always use https” is only an “on” option, there’s no “off” toggle.

Mmm didn’t remember that!

Would you mind sharing the domain name? Or at least post the headers for HTTP and HTTPS both on the root path and the one you don’t want HTTPS?

Thanks Matteo,

I’d rather not post the domain, yet, until we’ve done all the “lockdown” testing and double checked all security etc.

It doesn’t look like you can send PM messages via this forum, either.

But when you say the headers… what sort of info is it you want?

I can reach out to you via PM, if you would be willing to give it to me.

About the headers it would basically be doing this command with all the variations in the terminal:

curl -I

Thank you - certainly, here are those headers. It looks like the main setting of “http everything” and “no ssl” on page rules are just bouncing back and forth between each other. If only there WAS a setting for “Always Use HTTPS turned to off on that page rule” then it would instantly solve the problem, I think!

curl -I
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Oct 2018 13:02:25 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Thu, 25 Oct 2018 14:02:25 GMT
Expect-CT: max-age=604800, report-uri=""
Server: Cloudflare
CF-RAY: 46f4e0a37feb0cb3-LHR

curl -I
HTTP/1.1 301 Moved Permanently
Date: Thu, 25 Oct 2018 13:02:38 GMT
Connection: keep-alive
Cache-Control: max-age=3600
Expires: Thu, 25 Oct 2018 14:02:38 GMT
Server: Cloudflare
CF-RAY: 46f4e0f006a21377-LHR

I believe the main “Always Use HTTPS” kicks in before Page Rules. So you’d have to turn that feature off for your domain, then enable it elsewhere.

Because it’s just that one directory that needs it, Page Rules isn’t a viable solution, as Page Rules don’t have an Exclude pattern.

You’d have to enable HTTPS redirect at the server level so you can redirect all except that one directory, or possibly by using Cloudflare Workers.

EDIT: If you’re using Flexible SSL, then only the Workers approach would work, as you can’t do HTTPS redirects at the server level (it will screw up the Flexible SSL connection)

1 Like

Seeing the headers there are no reasons to actually check the website itself.

Unfortunately without the ability to disable that rule on the path there isn’t a lot that can be done except probably writing your own redirect on Workers ignoring that path. Obviously it would incur a cost, but it’s pretty limited (depending on the actual traffic obviously).

Is there no way to solve the issue. Not completely sure if buying a dedicated certificate would remove the SNI issue.

Have you tried contacting support?

I think I’ve figured it out - 3 page rules, in this order:

one tells everything at* to be https
the next tells everything at* to use automatic rewrites
and finally* tells everything to use https under that path to avoid mixed content errors

Been trying it for the last 10 mins, so far seems OK. Fingers crossed!



This topic was automatically closed after 14 days. New replies are no longer allowed.