CSS Not Loading for a handful of customers

#1

Over the last couple of months, I’ve heard from a handful of customers that our website will not display correctly. This is a handful out of probably 3-4,000 that buy from us annually. The only way I’ve been able to replicate what they are seeing based on their screenshots was to manually block CSS files from loading using Developer Tools.
Not sure if this is coincidence, but I discovered early on that all of the customers are in the same geographical region of the US. They are located in Kansas, Nebraska, Iowa, and Wisconsin. I thought it may be a specific ISP, but I know of at least three different ISPs being used, and one is the same ISP that we use internally. That being said, I’m not ruling out an ISP issue entirely. One customer uses Midco for service at home and her business, and the site will not load correctly at either location. However, if she goes to her boyfriend’s, who uses CenturyLink, the site loads just fine.

I spoke to a support tech at one of the ISP’s, and her computer was not displaying our site correctly either, and I managed to get a screenshot of her Network tab in Developer Tools, and all of the CSS files were blocked.

I initially thought it could be a caching issue, so one thing I tried was changing the names of a couple of the CSS files to force browsers to download the new files. This worked for a day or two for at least one of the customers

Aside from adding all of the CSS directly in the header, is there anything else that I can try to resolve this issue?

#2

From that screenshot, what was the HTTP Response Status Code for the blocked file?

#3

The screenshot I got from Midco’s support tech didn’t show that info. The Status column was no fully exposed. I’m reaching out to some of the users that are experiencing the issue to see if they will send me screenshots that show the error info. This screenshot was all I was able to get from them:

DT_Screenshot
DT_Screenshot.png560×900 54.4 KB

#4

“Blocked” might be within the browser. Can you have them check Dev Tools’ Console log for errors?

#5

You didn’t say what the domain is so I can’t test for this myself, but… maybe the links to your CSS are directly to http:// URLs whereas most of your users browse to your site with http:// and the ones with the issue browse with https:// ? That would lead to “mixed content” and certain objects blocked…

#6

Try to turn on Development Mode, wait 2mins and test again

#7

Thanks for the replies, everyone.

I reached out to a few customers earlier asking for a screenshot of their Console tab, the list of blocked files under Network along with the entire status, and the Response Headers for any different file types that may be blocked. i.e one of a CSS file, one of a .js file, etc. I’m completely at their mercy to provide this info, as I am not experiencing the issue and cannot naturally replicate it.

Apologies, I meant to include the domain when I first posted. It is www.bisqueimports.com

The CSS files that I manually blocked to replicate the screenshots I’ve seen are shown here, which shows how they are coded in the website backend.

08%20PM

If I am able to coordinate with one of these customers to be able to get before and after feedback when toggling Developer Mode, I will certainly try that.

#8

Interestingly in the page I’m loading now, those links that you mentioned are not relative, but begin with https://www.bisqueimports.com …

Obviously, I cannot replicate the actual issue :expressionless:

On a side note, it’s interesting to see that even though your Cloudflare TLS cert is recent (from January), it is not issued by Cloudflare itself, but instead is with a multi-domain like old certs. I am not saying it is relevant (but who knows…), just somehow strange…

By the way, it might also be interesting to see if those experiencing this, experience this in more than one browser…

As for other things instead of inlining the CSS, you could always put them on an external service like Amazon S3 with CloudFront :wink:

#9

I’m not sure about every case, but I do know that it is not browser specific for several of them. For one, it was happening on multiple devices on the their home and business network, but not on a friend’s network with at least one of the devices. The home and business network use the same ISP, their friend uses a different ISP.

I also know that for three of the users affected, their internet service is through three different ISPs.

#10

I just received a screenshot from one of the users, and the CSS files have mixed active content errors in the Console:

55%20AM
Screen Shot 2019-02-07 at 8.29.55 AM.jpg1782×910 471 KB

#11

The quickest fix for this is to add Content Security Policy to your .htaccess file:
Header always set Content-Security-Policy: upgrade-insecure-requests

This will tell the browser to always use HTTPS for your site and all its resources. That should stop the blocking.

#12

Would this be done within our Cloudflare account, or on our system? Our site is hosted by Netsuite, and from what I’m reading they don’t support htaccess.

#13

Do they have any way to add HTTP Response Headers?

If your site is configured for Full SSL on Cloudflare, you can also comb through your site to make sure there are no references to http for your domain.

You can also use Workers to add HTTP headers, but Workers is $5/month for your account. And if it’s a high-traffic site, there’s a Worker’s charge for anything past 10 million requests per month (or something like that).
https://scotthelme.co.uk/security-headers-cloudflare-worker/

#14

Have you tried enabling this under “Crypto” tab:

image
image.png1813×351 23.5 KB

?

1 Like
CSS files are being blocked again
#15

This is a bit over my knowledge level, but I don’t believe we are able to access where the Response Headers would need to be added. If I understand correctly, that would be done at the server level?

I know there are still a few references to HTTP that we haven’t cleaned up yet, but we moved to Cloudflare several months prior to receiving any report of this issue.

To shimi: Automatic HTTP Rewrites is currently enabled.

#16

It’s strange that Automatic HTTPS Rewrites is enabled and you don’t end up with https URLs… the only idea I have is that some “clever” JavaScript is constructing the URL on-the-fly on the client side, and thus Cloudflare doesn’t see it as an HTTP URL to rewrite. Another thing you can do, assuming all the URLs are on the same domain or subdomain thereof, is to enable HSTS, also under the Crypto tab; On modern browsers (Firefox 4+, Chrome 4+, Safari 7+, Edge 12+), this should cause your browser itself to upgrade all requests to your domain to HTTPS once it has seen even one request as HTTPS. Use a short TTL for starters though, in case you ever want to drop HTTPS. Once browsers has seen this directive, they’ll refuse to connect to your site as HTTP, and will always go immediately to HTTPS (this actually improves performance for users who just type in the domain and right now first go over HTTP, where they can be MITM-attacked using techniques like “SSLstrip”.

#17

If there is a client side script creating the HTTP URL’s, would that not affect all users instead of just a small number of them?

Would it be worth trying the absolute HTTPS versions of the URLs for a few of these to see if the affected users’ browsers will block them as well?

NetSuite assigns several URLs to files in the File Cabinet, as shown below. There are two that are HTTPS natively, which are used on their secure login and checkout pages.

13%20AM
Screen Shot 2019-02-12 at 10.43.13 AM.png1824×498 256 KB

#18

Not sure. Maybe they have them cached :slight_smile:

But HSTS should force the URLs to be HTTPS regardless how they’re actually written, so…

But it probably won’t solve the netsuite URL… they do not seem to have SSL service over the hostname shopping.na3.netsuite.com. Maybe they have alternative versions… maybe you’re using an old version (after all I see 2013 in the URL) and they have a more modern version that like most of the web is HTTPS… really you should ask them.

#19

Just for clarification, the 2013 in the URL refers to the website theme/skin.

I’ve reached out to all affected users trying to get the ‘cdn-cgi/trace’ info, and the two that I have heard from are both connecting to the MSP data center.

#20

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