Valet: Resource interpreted as Stylesheet but transferred with MIME type text/plain

[joedawson]

Hello,

None of my projects assets are loading in Valet for an existing project, in the console I see the following:

Resource interpreted as Stylesheet but transferred with MIME type text/plain: "http://rms.dev/assets/css/app.css".

It does appear though that this happens for all of my projects assets, for example if I try to view my javascript or another css file in the browser I just see a white page.

I'm not getting any 404's and viewing the network tab is showing 200 OK for each asset.

This isn't happening for external CSS/JS though

The thing is, it works fine if I use php artisan serve and my project is also fine on one of our servers in office (I'd prefer to use Valet though).

Here's my versions just so you know.

Valet Version: 2.0.3
PHP Version: 7.1.2
Laravel Version: 5.2
macOS Version: Sierra 10.12.3 (if this can be of any help?)

Any ideas how I could sort this out?

[joedawson]

I also just tried cloning one of my other projects, unfortunately seeing the same too.

I did look at #152 but I couldn't see if the guy managed to get anywhere with it.

I've also tried completely reinstalling valet etc.

Thanks

[ghost]

I'm having the same exact issue right now. thanks. (My versions are pretty much same as JoeDawson's above (Except I'm using Laravel 5.4), just incase anyone troubleshooting was curious)

[joedawson]

Did you have any luck @erichayesdev?

[joedawson]

I'm still stumped by this. I've done all of the following:

valet uninstall
sudo brew services stop nginx
sudo brew services stop php71
sudo brew services stop dnsmasq
brew uninstall nginx
brew uninstall php71
brew uninstall dnsmasq
rm -rf ~/.valet
rm /usr/local/bin/valet

Removed from composer

composer global remove laravel/valet

Then ran through installation steps.

brew update
brew install homebrew/php/php71
composer global require laravel/valet
valet install

Parked valet in my usual ~/Code directory

```
valet park
````

Still seeing the same problem, no idea what I can try next as I've removed and reinstalled (thoroughly) so many times. Any help would be appreciated.

[adamwathan]

Hey @JoeDawson can you push up a sample project that exhibits the issue? If I can replicate it locally I can try and troubleshoot.

[joedawson]

Hi Adam,

Sure - I've just set up a default Laravel app here: https://github.com/JoeDawson/test

Ran npm install and then npm run production for mix to compile the default assets with Laravel too.

Added the stylesheet to the head of the welcome.blade.php and can see that when I inspect the console I see the same error:

Resource interpreted as Stylesheet but transferred with MIME type text/plain: "http://test.dev/css/app.css".

When I manually try and view the file in my browser I just see a blank screen :(

Here's what actual file contents in my editor.

Really stumped with this, it worked fine before I upgraded to the latest - I can't recall what version I was on previously unfortunately though.

[adamwathan]

Annoyingly it works as expected here:

Can you try totally uninstalling nginx, updating to the dev-master version of Valet, and re-running valet install to see if that makes a difference?

Also what do the dev tools details look like for the network request to fetch the CSS? Can you take a screenshot so I can see all the headers and stuff?

[joedawson]

Hey @adamwathan, yeah it's odd - it works fine on my Macbook, I'm having this issues on my iMac at work (hence the slow response).

Here's what I did in regards to reinstalling and using dev-master

➜  ~ composer global require laravel/valet:dev-master
Changed current directory to /Users/joedawson/.composer
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 1 update, 0 removals
  - Removing laravel/valet (v2.0.4)
  - Installing laravel/valet (dev-master 4743c11) Cloning 4743c118d6 from cache
Writing lock file
Generating autoload files
➜  ~ sudo brew services stop nginx
Password:
Stopping `nginx`... (might take a while)
==> Successfully stopped `nginx` (label: homebrew.mxcl.nginx)
➜  ~ brew uninstall nginx
Uninstalling /usr/local/Cellar/nginx/1.12.0... (8 files, 1MB)
➜  ~ valet uninstall
Stopping nginx....
Valet has been uninstalled.
➜  ~ cd ~/Code
➜  Code valet install
Stopping nginx....
Installing nginx...
[nginx] is not installed, installing it now via Brew... 🍻
Installing nginx configuration...
Installing nginx directory...
Updating PHP configuration...
Restarting php71...
Restarting dnsmasq...
Restarting nginx...

Valet installed successfully!
➜  Code valet park
Password:
This directory has been added to Valet's paths.

Unfortunately still seeing the same :(

Here's a screenshot of the headers;

[adamwathan]

Ok so the interesting thing there is the X-Powered-By: PHP/7.1.4 header. That means nginx is ignoring the X-Accel-Redirect header we set and not serving the CSS file on Valet's behalf, which also explains why the file is empty.

I can't think of any reason why nginx would be ignoring that header, unless somehow your nginx configuration is different in some way.

Can you post your full nginx config file? Should be in /usr/local/etc/nginx/nginx.conf

[joedawson]

Hi @adamwathan, thanks for your reply. Here's what my nginx.conf looks like:

➜  ~ cat /usr/local/etc/nginx/nginx.conf
user joedawson staff;
worker_processes auto;

events {
    worker_connections  1024;
}

http {
    include mime.types;
    default_type  application/octet-stream;

    sendfile on;
    keepalive_timeout  65;
    client_max_body_size 128M;

    gzip  on;
    gzip_comp_level 5;
    gzip_min_length 256;
    gzip_proxied any;
    gzip_vary on;

    gzip_types
    application/atom+xml
    application/javascript
    application/json
    application/rss+xml
    application/vnd.ms-fontobject
    application/x-font-ttf
    application/x-web-app-manifest+json
    application/xhtml+xml
    application/xml
    font/opentype
    image/svg+xml
    image/x-icon
    text/css
    text/plain
    text/x-component;

    include /Users/joedawson/.valet/Nginx/*;
    include servers/*;
    include valet/valet.conf;
}

[adamwathan]

Can you share your valet/valet.conf, and any files in nginx/servers if there are any?

[joedawson]

Should I have a valet.conf somewhere? Here's whats in my ~/.valet directory;

➜  .valet ls -la
total 16
drwxr-xr-x   11 joedawson  staff   374  5 May 08:56 .
drwxr-xr-x+ 106 joedawson  staff  3604  5 May 12:45 ..
drwxr-xr-x    2 joedawson  staff    68  4 May 12:22 Certificates
drwxr-xr-x    3 joedawson  staff   102  4 May 12:22 Drivers
drwxr-xr-x    2 joedawson  staff    68  4 May 12:22 Extensions
drwxr-xr-x    3 joedawson  staff   102  4 May 12:22 Log
drwxr-xr-x    3 joedawson  staff   102  4 May 12:22 Nginx
drwxr-xr-x    2 joedawson  staff    68  4 May 12:22 Sites
-rw-r--r--    1 joedawson  staff    78  5 May 08:56 config.json
-rw-r--r--    1 joedawson  staff    24  5 May 08:56 dnsmasq.conf
srwxrwxrwx    1 joedawson  staff     0  5 May 08:56 valet.sock

[adamwathan]

It's in /usr/local/etc/nginx/valet/valet.conf

[joedawson]

Thanks, here is it:

➜  valet cat valet.conf
server {
    listen 80 default_server;
    root /;
    charset utf-8;

    location /41c270e4-5535-4daa-b23e-c269744c2f45/ {
        internal;
        alias /;
        try_files $uri $uri/;
    }

    location / {
        rewrite ^ /Users/joedawson/.composer/vendor/laravel/valet/server.php last;
    }

    location = /favicon.ico { access_log off; log_not_found off; }
    location = /robots.txt  { access_log off; log_not_found off; }

    access_log off;
    error_log /Users/joedawson/.valet/Log/nginx-error.log;

    error_page 404 /Users/joedawson/.composer/vendor/laravel/valet/server.php;

    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/Users/joedawson/.valet/valet.sock;
        fastcgi_index /Users/joedawson/.composer/vendor/laravel/valet/server.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME /Users/joedawson/.composer/vendor/laravel/valet/server.php;
    }

    location ~ /\.ht {
        deny all;
    }
}

[adamwathan]

Everything looks fine there, was thinking maybe this option was set somewhere:

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers

Can you run sudo nginx -t and see if it shows a path to a different config file?

[joedawson]

Yep sure, this is the path:

/usr/local/etc/nginx/nginx.conf

Output from test:

➜  ~ sudo nginx -t
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful

[adamwathan]

Really not sure what's going on, no idea what to check next :/ nginx normally sees those headers coming back from PHP and hijacks the response, then serves the file itself.

What version of nginx are you running? nginx -v to check.

[joedawson]

Yeah it's really baffling me too - I've set up Valet multiple times previously and never come across this, even Googling doesn't bring up much. I saw #265 but that was a different issue.

Here's my version:

➜  ~ nginx -v
nginx version: nginx/1.12.0

[adamwathan]

I'm on 1.10.3, so will try updating and see if it causes the same problem for me.

[joedawson]

Thanks again @adamwathan

[adamwathan]

Still works for me, weird :/

[adamwathan]

Is it just that CSS file that has that issue, do JS files serve properly or do they also come back empty?

[joedawson]

Unfortunately it happens with every local asset on any project, new or existing.

Could I potentially have something conflicting? For example I know Macs (at least used to) come with Apache installed as default, could that be potentially running and causing the issue?

[adamwathan]

It seems unlikely otherwise nothing would be hitting Valet at all :/

Can you show me the response headers in dev tools for a non-static request, liketest.dev from the screenshot above?

[adamwathan]

The root problem is your installation of nginx completely ignoring the X-Accel-Redirect stuff:

https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/

But I can't seem to find out if that's an optional module or something, or if there's a way to check if it's not enabled/installed.

[joedawson]

Here's the headers

[adamwathan]

Hmm interesting, check out mine:

Notice the Server: nginx/1.12.0 header? Wonder why that's not present in yours. I can't for the life of me understand how you could possibly be hitting Valet without going through nginx though.

What does sudo lsof -i :80 show in your terminal?

[adamwathan]

Also noticed you're not seeing gzip enabled, which is another sign that maybe you aren't hitting nginx at all somehow. Suuuper weird :/

[joedawson]

Very weird, here's what that command is saying:

php          69      root    3u  IPv4 0x3ac9ef2cc2a950db      0t0  TCP localhost:http (LISTEN)
Google    14854 joedawson  194u  IPv4 0x3ac9ef2ce35fb2cb      0t0  TCP 192.168.250.158:53401->lhr35s04-in-f3.1e100.net:http (ESTABLISHED)
Google    14854 joedawson  198u  IPv4 0x3ac9ef2ce360e2cb      0t0  TCP 192.168.250.158:53402->lhr35s04-in-f48.1e100.net:http (ESTABLISHED)
nginx     34206      root    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34207 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34208 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34209 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34210 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34211 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34212 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34213 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)
nginx     34214 joedawson    6u  IPv4 0x3ac9ef2cd244c0db      0t0  TCP *:http (LISTEN)

[adamwathan]

That first line is bizarre, PHP running directly on port 80? Can you kill -9 69 and then try hitting your site?

[adamwathan]

If that turns out to be the problem, it would be interesting to figure out how that process got started. I would do a history | grep php and look for anywhere in there where you started a PHP server and maybe forgot about it, haha...

If it's not in there, I'd reboot the machine and see if the process comes back. If so you'll have some digging to do to figure out what is trying to start PHP's built-in server on port 80, it's definitely not Valet.

[adamwathan]

The very first version of Valet might have done that actually, before we even switched to Caddy, so if you've had Valet on this machine for over a year then it could be a lingering process from then!

[joedawson]

Looks like that solved it! Assets are loading and the Server header is returning nginx :)

This machine shuts down and boots up at least once a day so I assume it's a process that starts on boot. It's also very likely that I installed a an early version of Valet, if not the first.

[adamwathan]

Nice! Can you ls -la /Library/LaunchDaemons and see if there is a Laravel/Valet looking file in there? If so, delete it :)

[joedawson]

Thanks Adam! Deleted the com.laravel.valetServer.plist file and rebooted - all of my projects seem to be working fine (including the test project I created yesterday).

Really really appreciate your help with this, can finally dump Homestead (again)!

[adamwathan]

Woohoooooo I did not expect to ever resolve this problem, haha...

[ghost]

nice! I was able to get mine fixed as well by removing the com.laravel.valetServer.plist file. 💯 👍 Thanks @adamwathan for the help! I'm excited to take your 'Test-Driven Laravel' course in the near future.

[ghost]

and thanks to @JoeDawson for providing all the info and working with @adamwathan through this issue. I hope this thread will save alot of Laravel devs in the future who come across this issue.

[SteveEdson]

Just a quick note to say that I also had this issue after upgrading Valet from V1. Running sudo lsof -i :80 showed me that Caddy was still handling the requests. Killing the process and running valet start solved it.

I'm guessing this means that nginx has been previously failing to start, due to the port already being in use. Can we get a error / warning about this when running valet start in future?

[kingbri90z]

Thanks for this @adamwathan. I've been having this problem for a while now.

[connor11528]

Hallelujah!

Running kill -9 69 and deleting /Library/LaunchDaemonscom.laravel.valetServer.plist fixed the issue

I had tried getting up and running with valet over a year ago. It wasn't working for me. I gave it another try this week, ran into this error and the solution fixed it so valet working now. Thanks @adamwathan and @JoeDawson for sticking with this

[vaibs2987]

I have fixed this issue by adding --mime-type='text/css'

[chriskacerguis]

So, I seemed to have encountered this (running 2.0.12). I ran through the fixes suggested here, but not of them applied / worked. On a strange note, everything was working fine (just drove home and woke up the laptop and this issue popped up). Any other ideas how to fix this by chance?

[asrar7787]

I installed valet+ on a fresh Mac and had the same issue for a Magento 2 project.
My response headers were correctly showing server and all other related stuff. I didn't have
/Library/LaunchDaemons/com.laravel.valetServer.plist in anywhere.
Running sudo lsof -i :80 didn't show me anything obsolete or stale PHP/NGINX process.

I fixed this as below:

1. Did valet stop.
2. Removed pub/static/adminhtml and pub/static/frontend.
3. Ran php bin/magento setup:static-content:deploy -j=1 -f.
4. Did redis-cli flushall.
5. Started valet by valet start.
6. Did redis-cli flushall again.

[r-martins]

I was having the same problem when using valet link topdir and accessing topdir.test/somesite which adds a ./css/some.css.
It was being included as text, causing the error

The stylesheet http://topdir.test/css/some.css was not loaded because its MIME type, “text/html”, is not “text/css”.

The issue could be solved in 2 different ways:

1. accessing topdir.test/somesite/ (with a / in the end)
2. linking the subfolder as a main site

Probably something wrong with nginx/valet+ config.

[pnoeric]

Same problem here-- Homestead is working great but my style sheet is being served as text/html, which means the browser isn't using it (but I can access it at the URL, no problem). Digging into configs.....

[pnoeric]

Yeah, it was an issue with the special site-type I had made. I forgot to add $headersTXT back into the special nginx location{} config block that I had set up. Easy-peasy to fix!

[AMS777]

I was having the same problem with CSS and Javascript files, that were being served as text/html. After trying everything I could think of during hours without any effect, it was automatically solved by restarting Chrome.