Custom CSS not loading because of wrong MIME type

[richardmtl]

I've gotten two reports of this. Here's the error I see in Safari:

Did not parse stylesheet at 'http://www.domain.tld/?custom-css=7821bc56c4' because non CSS MIME types are not allowed in strict mode.

Chrome seems to be ok. One user said FF was also having trouble, but I can't repro and I don't see any errors in the FF console.

Both users say this started happening as of 4.6, but I don't see anything related to it. Also, since Custom CSS is now a WordPress feature and not Jetpack, is this even Jetpack's issue?

3055481-t
3049487-t

[jeherve]

since Custom CSS is now a WordPress feature and not Jetpack, is this even Jetpack's issue?

I believe it is, since the separate stylesheet (vs. loaded inline) is handled by Jetpack, since #5974.

cc @georgestephanis

[georgestephanis]

It should be sending a text/css mime type already -- https://github.com/Automattic/jetpack/blob/master/modules/custom-css/custom-css-4.7.php#L88 -- is that not getting through somehow? Is that the wrong mime type?

[msonsona]

Hi. I'm one of the reporters. @richardmtl pointed me here for updates on the issue.

Yes, @georgestephanis, somehow the mime type is not getting through.
You can check at timumama.com how custom-css it's sent as text/html.

Let me know if you need any further information
Thanks

[georgestephanis]

@msonsona Howdy, and thanks for the follow-up!

For reference, the full headers received are as follows:

HTTP/1.1 200 OK
Date: Wed, 15 Feb 2017 19:19:46 GMT
Content-Type: text/html; charset="UTF-8"
Content-Length: 12098
Connection: keep-alive
Server: Apache/2.4.18 (Ubuntu)
Strict-Transport-Security: max-age=16070400; includeSubDomains
Vary: Cookie,Accept-Encoding
X-Mod-Pagespeed: 1.11.33.5-0
X-XSS-Protection: 1; mode=block
Cache-Control: max-age=0, no-cache

My guess at the moment is that something is overriding the Content-type header that Jetpack is sending -- which is likely a server configuration issue -- so something you may want to ask your host about. If they don't know anything about it, it's possible that another plugin is triggering output buffering and then adding that header after the fact on shutdown -- but far more likely is it being a host configuration issue, where they are running some sort of caching system that is rewriting the content-type.

The header Jetpack is sending is Content-type: text/css -- the one received is Content-Type: text/html; charset="UTF-8" -- both has more content, and the capitalization of Content-type is changed (as per RFC 2616 and 7230, the property in the HTTP Header is case insensitive -- so it shouldn't make a difference -- but it can be useful for tracking down what's actually generating that header).

[msonsona]

I'm hosting on AWS.
I have Google's PageSpeed module for Apache, maybe that could be causing the override?

[georgestephanis]

I really couldn't tell -- we'd likely need to do some investigating on the server and in the code itself to track down the cause. All I know at the moment is that /something/ is overriding the header that we're sending.

At this point it'd probably make more sense for this to be a support ticket, as it doesn't feel like it's a problem with the Jetpack code itself?

@richardmtl -- were there any similarities in the hosting environments that you could identify on the two reports we'd got?

[richardmtl]

No @georgestephanis ; one is using CF so I have little information to go on. If you think this should be a WordPress.org trac ticket, then let us know, so @msonsona can go ahead and open one there. (you said "At this point it'd probably make more sense for this to be a support ticket"; I'm not sure what you meant by that exactly).

[georgestephanis]

@richardmtl I meant the normal Jetpack support queues -- it doesn't seem to be an issue with the codebase, but a configuration problem somehow. Maybe I was misunderstanding how we're using different queues and tickets right now. :\

[richardmtl]

nope, I should have understood you, my apologies! However, if this is a server config issue, it's out of scope for Jetpack support as well, @msonsona . What I'm not 100% clear on is if this has anything to do with Jetpack at all, or if, since WP now handles Custom CSS, these two reports are best served by going to the WordPress.org forums. What is your thinking on that, @georgestephanis ?

[georgestephanis]

What I'd suggest is if @msonsona could create a php file on the server -- test-css.php and have it contain the following:

<?php
header( 'Content-type: text/css' );
echo "body {\r\n\tbackground: #f00;\r\n}\r\n";

And check to see how it's coming out when accessed. If it's showing the text/css header, then something in WordPress (another plugin conflicting maybe) is changing it. If it's coming text/html then it's a server configuration issue.

[georgestephanis]

I'm closing this for now -- but would be delighted to reopen if there's more data, or to help debug what is causing it.

[tsaiid]

I also encountered this problem. I tested the test-css.php by @georgestephanis, and the server replys text/css correctly, which may imply it is not a server configuration issue. What I could do was to disable the Custom CSS by Jetpack and let WP to handle this.