Redirect infinite loop ONLY on www CNAME

slucca · February 26, 2021, 11:14pm

Hi there, I am migrating my CDN solution to Akamai, and for the time being I will be using Cloudflare as a DNS server until I later migrate that piece out to Dyn.

I have a *.website.com certificate on both Cloudflare and the Akamai property.
I have these lines set in our .htaccess file

  # if you enable "www." stripping or enforcement, in order to ensure that
  # you don't bounce between http and https.
  RewriteRule ^ - [E=protossl]
  RewriteCond %{HTTPS} on
  RewriteRule ^ - [E=protossl:s]

  # Make sure Authorization HTTP header is available to PHP
  # even when running as CGI or FastCGI.
  RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

I made a new property to point to the origin in Akamai and I was able to point our m.website.com CNAME to the property, our website.com DNS record to the Akamai property, but when I go ahead and point our www.website.com to the Akamai property I end up with an infinite 301 redirect.

I ran a few cURLs on the endpoint during the outage and was able to determine cloudflare is doing the redirects, I also had the app teams check that the origin was not performing redirects.

I did read over this page
I have turned off all page rules with the exception of our cache bypass so that isn’t the problem
I do have HSTS enabled, but I don’t see why that would only affect this one CNAME!

Has anyone seen this behavior before?

cURL output, you can see on the final lines this redirect is happening from cloudflare

 curl -I -H "Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no, akamai-x-get-request-id,akamai-x-get-nonces,akamai-x-get-client-ip,akamai-x-feo-trace" https://www.WEBSITE.com
HTTP/2 301
date: Fri, 26 Feb 2021 13:07:53 GMT
content-length: 0
set-cookie: __cfduid=d24ccc784b2a0c7a25fa62c069769c5881614344873; expires=Sun, 28-Mar-21 13:07:53 GMT; path=/; domain=.WEBSITE.com; HttpOnly; SameSite=Lax; Secure
location: https://www.WEBSITE.com/
cache-control: max-age=0
x-cache: TCP_MISS from a23-74-3-126.deploy.akamaitechnologies.com (AkamaiGHost/10.3.0.1-32633187) (-)
x-cache-key: /L/16382/1155662/10m/WEBSITE-drupal-8-prd.us-east-1.elasticbeanstalk.com/
x-cache-key-extended-internal-use-only: /L/16382/1155662/10m/WEBSITE-drupal-8-prd.us-east-1.elasticbeanstalk.com/ vcd=8497
x-true-cache-key: /L/WEBSITE-drupal-8-prd.us-east-1.elasticbeanstalk.com/ vcd=8497
x-akamai-session-info: name=AKA_PM_CACHEABLE_OBJECT; value=true
x-akamai-session-info: name=AKA_PM_FWD_URL; value=/
x-akamai-session-info: name=AKA_PM_PROPERTY_NAME; value=www.WEBSITE.com
x-akamai-session-info: name=AKA_PM_PROPERTY_VERSION; value=6
x-akamai-session-info: name=AKA_PM_SR_ENABLED; value=false
x-akamai-session-info: name=AKA_PM_TD_ENABLED; value=true
x-akamai-session-info: name=AKA_PM_TD_MAP_PREFIX; value=ch
x-akamai-session-info: name=ANS_PEARL_VERSION; value=0.12.0
x-akamai-session-info: name=FOFR_PERF_CIP_BUCKET; value=2744
x-akamai-session-info: name=FOFR_PERF_HASH; value=274464
x-akamai-session-info: name=FOFR_PERF_TIME_BUCKET; value=93
x-akamai-session-info: name=MCH_BUCKET; value=2319
x-akamai-session-info: name=MCH_BUCKET_ARLID; value=1315
x-akamai-session-info: name=MCH_BUCKET_PATH; value=4
x-akamai-session-info: name=MCH_MAP; value=mch-essl-so-sr2319.akasrg.akamai.com
x-akamai-session-info: name=MCH_SERIAL; value=66815
x-akamai-session-info: name=MCH_SERIAL_ARLID; value=1275
x-akamai-session-info: name=MCH_SERIAL_PATH; value=4
x-akamai-session-info: name=MCH_TRAFFIC_LANE; value=69
x-akamai-session-info: name=MPULSE_DEFAULT; value=true
x-akamai-session-info: name=OPT_CID_FORMAT3_CUSTOMER_CONTROL; value=1
x-akamai-session-info: name=OVERRIDE_HTTPS_IE_CACHE_BUST; value=all
x-akamai-session-info: name=PCH_SERIAL_HASH; value=816
x-akamai-session-info: name=PCH_SERIAL_PREFIX; value=e
x-akamai-session-info: name=PCH_SITE_SHIELD_MAP; value=chws.akamaiedge.net
x-akamai-session-info: name=PCH_SS_SERIAL_PREFIX; value=e
x-akamai-session-info: name=RO_ENABLED; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_BYPASS_MODIFY_PATH; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_CACHE_OVERRIDE_FIX; value=true
x-akamai-session-info: name=RO_IMPL_ROLLOUT_CLOUDLETS; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_CUSTOMER_TTL; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_CUSTOM_NOT_FOUND_474; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_EDGE_CACHE_TAG; value=true
x-akamai-session-info: name=RO_IMPL_ROLLOUT_REDIRECT_CHASE_OFF; value=false
x-akamai-session-info: name=RO_IMPL_ROLLOUT_SVG_SUPPORT; value=true
x-akamai-session-info: name=RO_VERSION; value=1.11.0
x-akamai-session-info: name=RUA_IMPL_CERT_CHECK; value=true
x-akamai-session-info: name=TCP_OPT_APPLIED; value=medium
x-akamai-session-info: name=TPM_SAFARI_MOBILE_SUPPORT; value=true
x-akamai-session-info: name=Y_HATS_CIP_BUCKET; value=8200
x-akamai-session-info: name=Y_HATS_CIP_HASH; value=820029
x-akamai-session-info: name=Y_HATS_TIME_BUCKET; value=58
x-serial: 16382
x-check-cacheable: NO
x-akamai-request-id: 4269cecf
x-akamai-pragma-client-ip: 162.158.122.116, 128.136.192.22
cf-cache-status: DYNAMIC
cf-request-id: 08800cfcbe0000371d8731b000000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"max_age":604800,"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=NEwi4tTqrfydD7grqA31%2BI0NmH%2BGih5YSvtCCM9cxTP7sEUE5pkzV03dmCXTuoo4%2FpsYSKOehyxUCtCjWlR4bmxK%2B3%2BjqBsa%2F7%2F9ha9S"}],"group":"cf-nel"}
nel: {"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=10368000; includeSubDomains
server: cloudflare
cf-ray: 6279e4413971371d-MIA

Please help! Thank you!

sdayman · February 27, 2021, 12:16am

Why do you think this redirect is happening because of Cloudflare? The only way that could happen is if you deliberately created a Page Rule that improperly 301 redirects to HTTPS, which I highly doubt you’d do.

Unless you’re using Flexible SSL mode which is a terrible setting to use. It should be Full (Strict).

slucca · February 27, 2021, 2:31pm

I think it’s cloudflare because the curl request responds with
server: cloudflare

if it were wordpress, wouldn’t it be
server: wordpress?

server is typically a descriptor for the software that responded to the request.

slucca · February 27, 2021, 2:32pm

And yes, we are in flexible SSL mode. Curious however if these SSL modes even matter when the records are plain DNS? If it does im happy to modify us to strict.

sdayman · February 27, 2021, 2:42pm

WordPress isn’t a server. Anything proxied by Cloudflare is served by the edge nodes (Server: cloudflare).

You didn’t mention Plain DNS. SSL Modes doesn’t impact DNS Only records. But if your CNAME functions with HTTPS when set to DNS Only, then Full (Strict) should fix this problem.

slucca · February 27, 2021, 8:54pm

Yeah we have nginx in front of the server so it would have said server:nginx, but anyways I will give that a shot on monday. Yes, our CNAME connects to Akamai, which connects to the server via HTTPS.

slucca · February 28, 2021, 10:47pm

Another question for you,
In the event that this takes down our site, how fast is it to switch between SSL modes? If we turn on strict and experience an outage, will turning back on flexible and restoring the previous configuration be instant or will it take some time?

Thanks for all your help.

system · March 5, 2021, 10:47pm

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