Update 3:

I've experimented a bit with setting ContentType for all css files to different types like text/plain, text/html and text/css in the .htaccess file of the webserver hosting Owncloud and when running curl --head http://www.<myDomain>.com/core/css/styles.css?v=abbcfa8606670b201527db15c9717a61 from the reverse proxy server, the changes are reflected in the Content-Type header.

However when running the same curl command directed at the reverse proxy I only get the same Content-Type text/html; charset=UTF-8

Update 2:

I've compared the http response headers when accessing the page directly and via reverse proxy and I've found that when going directly and requesting a css file the Content-Type is text/css but when going through reverse proxy it is text/html; charset=UTF-8.

Why does the proxy change Content-Type and how can I prevent it? I've tried setting DefaultType None in apache2.conf but doesn't make any difference.


In google chrome I also get variants of the error message

Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://<my-server-address>/core/css/styles.css?v=f8ed568350f3f0107c10d8e06c55f727".

If I remove the line from .htaccess

Header set X-Content-Type-Options "nosniff"

I no longer get the error message about strict MIME type checking but I get the same "Resource interpreted as Stylesheet" messages and also variants of:

Uncaught SyntaxError: Unexpected token < oc.js?v=f8ed568... :1

The following are my http headers:

HTTP/1.1 200 OK Date: Fri, 08 Apr 2016 20:04:11 GMT Server: Apache/2.4.7 (Ubuntu) X-Powered-By: PHP/5.5.9-1ubuntu4.14 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src * X-XSS-Protection: 1; mode=block X-Robots-Tag: none X-Frame-Options: SAMEORIGIN X-Download-Options: noopen X-Permitted-Cross-Domain-Policies: none Content-type: text/html; charset=UTF-8 Set-Cookie: ocirse4el2n4=0aad97s9uv1g5sclishd7sev85; path=/; HttpOnly Set-Cookie: oc_sessionPassphrase=YFrm%2BphkwzrtmgZ%2BJPnv9%2BJXZ4jYMK7TRPuHrgyoJ324CiFcGDm%2FrVITkXEjLDZXYUw%2BGLGrXe1tt8v3YZiHabYyd3Muwfq7BTcY%2FuFzVimQxYGCa682%2FDehZGG0HyRS; path=/; httponly

I have two ubuntu servers 14.04 running apache 2.4.7, mysql Ver 15.1 Distrib 10.0.22-MariaDB and php 5.5.9.

One of them is internal with no Internet access running an owncloud server and the other is facing the Internet with an apache server running a reverse proxy for the internal server to enable access to owncloud from the Internet.

The problem I'm having is that when going through the reverse proxy the webpage loads but most of the content seems to fail and the website doesn't work as expected. If I open the console I get the variants of the following error messages:

In firefox console:

The stylesheet <my-server-address>/core/css/jquery.ocdialog.css?v=f8ed568350f3f0107c10d8e06c55f727 was not loaded because its MIME type, "text/html", is not "text/css".
SyntaxError: expected expression, got '<'

In google chrome console:

Refused to execute script from '<my-server-address>/index.php/core/js/oc.js?v=f8ed568350f3f0107c10d8e06c55f727' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Accessing owncloud webpage internally works good which is why I think that the problem is with the reverse proxy.

This is how it looks when going through the reverse proxy:

This is how it looks when going through the reverse proxy

And this is how it looks when going locally: enter image description here

Also note that the button on the first picture is not responding.


If your proxy server or container adds the following header when serving the .css file, it will force some browsers such as Chrome to perform strict checking of MIME types:

X-Content-Type-Options: nosniff

Remove this header to prevent Chrome performing the MIME check.

  • Any idea why the problem only shows up while going through the proxy? – Jimmy Apr 4 '16 at 7:09
  • @Jimmy It could be the proxy adding the header. – Analog Apr 4 '16 at 7:34
  • I retrieved the http headers from visiting the page directly and from going via the reverse proxy and both set the X-Content-Type-Options: nosniff. – Jimmy Apr 6 '16 at 19:41
  • @Jimmy if you view the page directly does the css show "type="text/css"" or "type="text/html"" ? Is it different from proxy vs direct? – Analog Apr 6 '16 at 20:46
  • Initially it was: Content-type: text/html; charset=UTF-8 on both direct and proxy. I tried changing it to: Content-type: text/html; charset=UTF-8; text/css .css; text/javascript .js but it doesn't seem to make any difference – Jimmy Apr 6 '16 at 20:49

I finally found out that I was missing a trailing / on the ProxyPass commands.

Previously I had written:

ProxyPass / http://cloud.myDomain.com
ProxyPassReverse / http://cloud.myDomain.com

It should be:

ProxyPass / http://cloud.myDomain.com/
ProxyPassReverse / http://cloud.myDomain.com/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.