I am attempting to serve my static blog (powered by jekyll) on my Ubuntu server but the CSS does not apply and I keep getting the issue:
"Resource interpreted as Stylesheet but transferred with MIME type text/plain".
In the source code, however, I explicitly list that these files are "text/css". Any ideas on how to solve this?
This was an Nginx issue. I needed to place
include /etc/nginx/mime.types;
in the "location /" block.
Check if you have set "rel='stylesheet' attribute.
Related
I'm new to nginx and I like it.
I'm putting up a few scgi feeds, and some static content.
After creating a home page hierarchy under /home, I went to move it to /.
But when I put it there the .jpg and .jpeg images were coming back 404.
sitename.com/test.gif is found just fine.
sitename.com/test.jpg is 404
but creating a a subdirectory, and copying test.jpg work.
sitename.com/subdirectory/jpg is fine.
I'm running with pretty empty config files as they were installed under Ubuntu 18.
I'd REALLY like to know what's going on here, and why top level .jpg/.jpeg files are doing this.
I know I could create a location directive as follows:
location ~ \.(jpg|jpeg)$ {
root /real/location/of/my/home/;
}
But that breaks access to .jpg/jpeg files in the scgi locations served from other roots.
I found it! It wasn't the jpg/jpeg suffix. It was the filename!
I have a /wdc location that is an scgi script.
A file in / that begins wdc for example /wdc-face.jpg goes through to scgi.
Many of the nginx example give locations without trailing slashes. But I think that a trailing slash is what people should be encouraged to use by default
We had a security check on our application, and it reported a few issues like missing charset attribute for .css and .js files.
Attack Type: Undefined charset attribute
Error Description: The Content-Type HTTP header is missing charset attribute
Content-Type: text/CSS
I found this answer The Content-Type HTTP header is missing charset attribute
Our application has been developed using play framework and I tried to add in the application.conf like this
AddDefaultCharset : utf-8
AddCharset utf-8 = [.htm .html .js .css]
But it didn't work. How can I resolve this issue in our application?
Thanks
Maybe You can try this one.
application.conf
play.filters.enabled += "play.filters.headers.SecurityHeadersFilter"
change this one, as Play Docs instructed.
play.filters.headers.contentTypeOptions -
sets X-Content-Type-Options, “nosniff” by default.
Source here.
I've just installed a fresh and clean Symfony app. I'm using NGINX as my webserver.
The stylesheets don't show a http 404 error code in devtools network-tab and i can see their content in the preview-tab correctly.
example picture:
Did someone face any issue like this? I'm guessing it might be a permission issue...
EDIT #1: Attached a picture of the chrome devtools showing the css are loaded correctly.
You need to make sure your nginx.conf actually includes the correct mime-types.
http {
include conf/mime.types;
# ...
... or ...
types {
# ...
text/css css;
I'm currently migrating from lighttpd to nginx.
I've got some weird files (don't ask why):
1. say a file named 'news', which actually should be more like news.txt
2. a file named '.html', which actually should be index.html
With lighttpd, simply rewrite those things would work.
Nginx would still locate those files with try_files or rewrite, but I've got no control of the content type returned. I mean if the file is named '.html', the content type is 'application/octet-stream'.
I know I can use more_set_headers to achieve that, but is there any other way to do that? I mean why does nginx think a file named '.html' not an html file?
I mean why does nginx think a file named '.html' not an html file?
A dot at the beginning in unix-like systems is usually used as the indicator of hidden files. In this case, a part after the dot isn't file extension.
I know I can use more_set_headers to achieve that, but is there any other way to do that?
You should use the default_type directive instead of 3-rd party modules.
For example:
location =/.html {
default_type text/html;
}
I have a gzip-compressed style and scripts in files:
/scripts.js.gz
/styles.css.gz
The problem is that it does not serve the correct mime-type and browser does not recognize, that the files are compressed css or js (browser recognize the type as application/octet-stream, where it should be text/css or so).
I tried adding the following to mime.type of nginx, but with no effect. I suppose, it does not recognize, that the file is compressed.
types {
text/css css.gz;
application/x-javascript js.gz;
}
When trying to access the files, the browser handle the files as files to download and not to present.
I had the same problem, coming from Apache.
The problem I found is, the types block does not allow you to specify .css.gz as a file extension. However, the location block does! My solution is to make a location for .css.gz and then modify the content type for .gz within that location, like this:
location ~ \.css\.gz$ {
add_header Content-Encoding gzip;
gzip off;
types {
text/css gz;
}
}
Do not change the mime types and use the Gzip Static Module to handle this.
When this is active, Nginx will try to serve "file.ext.gz" first and then try "file.ext", if not found, for all requests within the context (location etc) where it is active.