I have an nginx server that is showing a 200 response in my browser for requests like
https://server.com/app/static/js/2.8cc049f3.chunk.js
and showing a 304 on the server logs
"GET /static/js/2.8cc049f3.chunk.js HTTP/1.1" 304 0 "https://server.com/app"
There is another nginx in front of the nginx running on server.com that is removing the app from the path. Based on the nginx logs on server.com this is working correctly. The static folder is in my root /usr/share/nginx/html/.
The content my browser receives for the js file is the index.html. However when I login to the server and run
curl http://localhost/static/js/2.8cc049f3.chunk.js
I get the correct js content in response and in the logs the server prints 200
"GET /static/js/2.8cc049f3.chunk.js HTTP/1.1" 200 1570391 "-" "curl/7.80.0" "-"
Here is my nginx.conf
server {
listen 80;
root /usr/share/nginx/html/;
index index.html;
add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {
try_files $uri $uri/ /index.html;
}
location ~ ^/(static)/ {
gzip_static on;
gzip_types
text/plain
text/xml
text/css
text/comma-separated-values
text/javascript application/x-javascript
application/atom+xml;
expires max;
}
}
I've read that a 304 means the file hasn't changed and tells your browser to use its local cache, so I cleared my browser cache. I also restarted nginx, thinking that the first request would give a 200 response on the server but it was still a 304.
Based on the local curl request being successful I don't think there is anything wrong with my nginx.conf. I don't know if nginx somehow has the index.html cached as the content of my js, or if I didn't clear my browser cache correctly.
I'm also confused why the response code is 304 on the server but 200 in my browser.
The HTTP 304 says "Not-Modified". This is because you are using another NGINX Proxy server in front of the NGINX Server we are talking about.
The 1st NGINX is requesting a resource on the 2nd NGINX and this one answers "Hey that file was not modified since the last time you have asked".
In this case it would be very helpful to check the configuration of the 1st NGINX Proxy instance or your turn of the caching in the first one and proxy_cache off; and check the result.
Related
I have the following nginx.conf:
events {}
http {
server {
index index.json;
location /api/some-folder {
alias /some-folder;
default_type application/json;
add_header Content-Type application/json;
}
}
}
With that in place, when the nginx docker image is served on port 8080 and has my json files packed in folder /some-folder, I can browse
http://localhost:8080/api/some-folder/
and I get the content of /some-folder/index.json back. Furthermore, when I browse
http://localhost:8080/api/some-folder/subfolder_1/subfolder_2/some-json.json
then I get the content of /some-folder/subfolder_1/subfolder_2/some-json.json. All fine.
My issue is that I can't seem to find a way to get the /some-folder/index.json content when I browse
http://localhost:8080/api/some-folder
with no trailing slash. When I browse that, I get redirected to
http://localhost/api/some-folder/
which doesn't exist, because nothing is served on port 80. I think I am missing something on how nginx works, and I'd appreciate some help to make it work.
If I simplify my location to just /, then the following configuration works perfectly with and without trailing slash:
events {}
http {
server {
index index.json;
location / {
root /some-folder;
default_type application/json;
add_header Content-Type application/json;
}
}
}
I would like the same behavior as that, but with a location /api/some-folder.
EDIT
Please find here a github repository where the issue is reproduced.
The requirement is to access the burger service in https://meals.food.com/burger2.
The context path within the app is /burger.
Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /burger/$2
spec:
rules:
- host: meals.food.com
http:
paths:
- backend:
service:
name: burger
port:
number: 80
path: /burger2(/|$)(.*)
pathType: Prefix
Upon checking the ingress controller logs:
[05/Jan/2022:13:54:11 +0000] "GET // HTTP/1.1" 304 0 "-" "Mozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/96.0.4664.110 Safari/537.36" 957 0.002 [anotherservice-80] []
x.x.x.x:80 0 0.002 304 230200x023
Is my ingress config correct?
My suspicion is that something is altering the request between my request from the browser to ingress-controller.
Is my ingress config correct? My suspicion is that something is altering the request between my request from the browser to ingress-controller.
Your ingress config looks OK. I do not see any errors in it. He will act as follows:
The example address meals.food.com/burger2/blah-blah-blah will be rewirted to meals.food.com/burger/blah-blah-blah. If that was your intention then config is fine.
However you have got 304 HTTP code.
The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses a If-None-Match or a If-Modified-Since header.
The equivalent 200 OK response would have included the headers Cache-Control, Content-Location, Date, ETag, Expires, and Vary.
In other words
When the browser receives a request, but does not know whether it has the latest version of a write, it sends a conditional validation request, communicating the last modified date and time to the server via the If-Modified-Since or If-None-Match header.
The server then checks these headers and determines if their values are the same. If so - the server will send back the HTTP 304 code and the browser will use the cached copy of the resource. If not, it means that the file has been modified, so the browser will save a new copy by sending HTTP 200 code.
In your case it looks as if someone tried to download the same (unchanged) resource multiple times and therefore got the code 304. If so, everything is fine.
My contact.html file is being downloaded rather than rendered in the browser when running my site on NGINX.home.html is working properly. This is how my default (in folder sites-available) file looks like:
server {
listen 90;
listen [::]:90;
server_name example.com;
root /home/myname/www;
location / {
try_files $uri /home.html;
add_header Access-Control-Allow-Origin *;
}
location = /contact {
default_type text/html;
alias /home/myname/www/contact.html;
}
}
When I add /contact to my url on my browser, contact.html gets downloaded as unknown file format. After having done an extensive search, these are the things I've tried:
Clear the browser cache (it also happens in Edge, so clearly this isn't the issue)
In nginx.conf I commented out the default_type application/octet-stream and un-commented default_type text/html
I have checked the in mime.types file the type text/html exists.
using try_files $uri /contact.html
Any help will be appreciated!
The issue was that default_type text/html property in nginx.conf lives in http {...} block. Since my server is listening to port 90 this configuration does not apply. once I changed the port to 80 the issue was resolved.
Hey there,
I'm new when dealing with NIGNX servers and Linux. My HTML file is displayed but my server does not load the CSS files.
The only thing I found was this line
include /etc/nginx/mime.types;
which I include in the http block.
After that I reload my config with sudo nginx -s reload. To be sure I also executed sudo nginx -s stop and sudo nginx.
This is my whole config:
http {
include /etc/nginx/mime.types;
server {
location / {
root /data/www;
}
location ~ \.(gif|jpg|png)$ {
root /data/www/images;
}
}
}
events {}
My skeleton files are located in /data/www. In this directory there is another CSS folder.
Thank you in advance.
First of all, you're going to need to tell NGINX to have your static files to obtain a TTL (time to live) via expire headers. Locate this in your NGINX configuration file, if it isn't there. Create a new directive with location
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 1s;
}
After this go ahead and purge your files from the server and force it to serve new files.
Set sendfile off in nginx.conf
Set expires 1s in mysite.conf
Explicitly set Cache-Control header: add_header Cache-Control no-cache;
Of course, before doing anything above. If it doesn't require drastic measure, try manually deleting everything in the cache folder: /var/cache/nginx
If that doesn't help then proceed with everything listed here!
After you've successfully purged your server from serving static files. Add this to your NGINX server block to achieve optimization.
gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain application/x-javascript text/xml text/css application/xml;
It's possible to set expire headers for files that don't change and are served regularly.
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
I'm running Apache 2.4.7 on Ubuntu Server 14.04
I have a webserver running. It returns 304 modified for images, but it doesn't return the same for json files. I have checked the answers and comments for this post and this post, however, they don't work for me.
In my .conf file, when I do not load mod_deflate, the server returns a 304 response for my json file. But when I GZIP this file, the server returns 200 OK.
This is what I add to my apache2.conf file:
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript
</IfModule>
Any workaround to enable both mod_deflate and 304 for .json files?
Thanks!
Simply set Etag to NONE in apache config.
Having mod_deflate on will append -gzip to Etag, which server then doesn't accept.
Look at the mod_deflate spec
AddSuffix Append the compression method onto the end of the ETag,
causing compressed and uncompressed representatins to have unique
ETags. This has been the default since 2.4.0, but prevents serving
"HTTP Not Modified" (304) responses to conditional requests for
compressed content.