Shulou(Shulou.com)06/02 Report--

After running into a page of nginx agent recently

Proxy_pass http://8.1.1.1:6080/binding.html;

The problem that js loads successfully but css fails to load.

Solution:

Add to 1.http {}

Include / usr/local/openresty/nginx/conf/mime.types

Default_type application/octet-stream

two。 Or change the type of css in mime.types to application/octet-stream

Reason: when the web server communicates with the browser on the Internet, all data needs to be specified as a file type (type), otherwise the browser does not know what plug-in to use to process the data, such as mid,.midi audio/midi,audio/x-midi and other types of audio data.

After the css file in my server is proxied by nginx, nginx looks for the type definition of the css file in the original html:

There is no typewritten cake!

So I made a mistake! Nginx does not know what encoding to use to transfer such files (it does not know what css)

So after defining default_type application/octet-stream, nginx agrees to forward it according to the type of byte stream, regardless of the file type, so that it is finally transferred to the client browser.

So the question is, since the nginx side is forwarded to the browser with a byte stream, and the browser does not know that this is a css file, it is just a bunch of byte streams, why can it still be loaded?

Because mainstream browsers can also recognize css files by default, many developers have become accustomed not to write this to css, but for many special data types, it is best to define them.

In particular, agents like nginx are lightweight and not as powerful as browsers, so developers should be more rigorous in order to consider compatibility! I really want to complain! This question stuck me all afternoon!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.