We Keep Coding

Serving files from Vite server.fs does not work in node 18+

We've been using node.js 16.16.0 with Vite(our monorepo is managed using rush with pnpm under the hood), and we were serving some files using server.fs configuration(https://vitejs.dev/config/server-options.html#server-fs-allow).
In node 16.16 everything works as expected, more or less, allow option as well as deny option serve their purpose. However, after upgrading node to 18.13, the functionality of serving files from filesystem does not work at all, and there is very little to work with.
Every request for specific file, that works in node 16.16 returns with Error: connect ECONNREFUSED 127.0.0.1:5001 where 5001 is our dev port. Host and port are set correctly.No suspicious error messages in the console etc.
It looks like the files are not beeing served under this urls at all. Using deny changes nothing, still the response is ECONNREFUSED(in 16.16 it's 403 Restricted).
I upgraded Vite to the newest version, error still the same.
I'm slowly running out of ideas, I will appreciate any help.

Ok, I found the issue... It's so dummy and has nothing to do with Vite... In node 17+ they are no longer treating IPv4 as default, but they are taking the OS system configuration into account.
Node.js no longer re-sorts results of IP address lookups and returns them as-is (i.e. it no longer ignores how your OS has been configured). You can change the behaviour via the verbatim option to dns.lookup() or set the --dns-result-order command line option to change the default.
It means that application on this node version will no longer serve anything on 127.0.0.1(IPv4), but on ::1(IPv6). Switching from '127.0.0.1' to 'localhost' did the trick in my case.

Kibana stuck on loading screen [UPDATE - Nginx only serving partial JS file]

Kibana is not starting up properly. When I open up the console it appears to be a javascript resource issue. When I open the js files directly (clicking on their link in the console) it appears they are incomplete and have been abruptly been cut off. Not sure if this is a browser file limit or somehow my files have been cut off? Please see the images below to show you what Im seeing.
File as seen in chrome. This is the very bottom of the file as per how chrome loads it.
I have restarted kibana to see if that would resolve it, no luck.
I think browsers have a max line limit in js files. I am not sure why kibana hasn't minified the js files? has it started up in some dev mode?
question summary
I guess I have discovered the reason for kibana not loading is because of the js not fully loading, this would change my question to how can I get all of my javascript to load?
Update
I have located the JS files in the kibana bundles folder and found that the file is fully intact. It is indeed a browser loading complete file issue. I'm confused why suddenly those files are too long to be loaded by the browser? Was working fine a fortnight ago. Still trying to work out how I can get chrome to load the files.
As suggested by #asettouf I have removed(backed up) bundles folder in the /opt/kibana/optimize directory and started kibana up again. This did re-generate the bundles folder but the files are identical, meaning I still have the same issue. How come Kibana is not minifying the js when it bundles the files for caching?
My kibana.yml. I think it is cleaner to paste a link to it:
http://www.heypasteit.com/clip/O8HUN
went back turned on verbose logging and this is my output from deleting optimize folder and restarting. nothing stands out as an error message to me.
/var/log/kibana/kibana.log
replaced hostname with localhost for privacy and security reasons
http://www.heypasteit.com/clip/OA4OR
I think this is an error with the webpack module not compiling the JS correctly. however i dont know enough about the module to debug it.
the files in question in the optimize folder are:
commons.bundle.js which is 65723 lines
kibana.bundle.js at 108950 lines
These are far from optimized and the content inside the files are not minified.
Result of curl -v localhost:5601
http://www.heypasteit.com/clip/OEKEX
CURL REQUEST DIRECTLY TO KIBANA JS RESOURCES
I can confirm that curl -ukibanaadmin -v http://localhost/bundles/commons.bundle.js returns me the full 108950 lined JS file and curl -ukibanaadmin -v http://actual_kibana_hostname/bundles/commons.bundle.js returns the same content (number of lines) as my browser.
With that information I can make the assumption that this is not a Kibana issue at all. As mentioned by #val it is probably a setting in nginx that is preventing the entire file from being served unless accessed by localhost.
I think I can rule out Cloudflare as I still get the issue when I hit my server directly from the browser.
Thanks to everyone's suggestions and help so far. Getting closer and closer to solving my issue. I will do some more research on Nginx and its settings.
NGINX UPDATE
Nginx appears to only be loading the first 72kbs of my havascript files. Ive search all around my nginx config files and cannot see this setting anywhere. Ive added things like
location / {
...
proxy_max_temp_file_size 1m;
...
}
and
location / {
...
sendfile on;
sendfile_max_chunk 1m;
...
}
But still I'm unable to overwrite this weird setting that is only allowing first part of file being loaded.
The connection uses nginx proxy_pass to foward port 80 to kibanas port '5601'. I feel like there could be a setting that limits file transfer over proxy? just not sure where to find it.
proxypass connection looks like:
server {
listen 80;
server_name logs.mydomain.com;
auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/htpasswd.users;
location / {
proxy_pass http://localhost:5601;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
And my default nginx settings is posted here.
/etc/nginx/nginx.conf
http://www.heypasteit.com/clip/OEKIR
I have tried adding sendfile_max_chunk 512k and changed worker_processes from 4 to 2. Any other config things were already there. I was not the the one who initially set up the ELK stack.
And after the mentioned changes it looks like this:
/etc/nginx/nginx.conf
http://www.heypasteit.com/clip/OEKF0
ERROR RETURNED - DISK SPACE UPDATE
This issue has come back. When I checked the VMs health I noticed that the disk drive was full. Elasticsearch was logging a couple of GBs worth of text in to error logs each day. I still Have not fully identified why elastic search is flooding the error logs.
But I think excessive disk space usage has contributed to this error. Nginx could be detecting this and switching over to minimal safe configuration which would only allow 72kbs of data to be served per file.
When I cleared out the excessive logs i stopped getting the incomplete js error without needing to restart nginx or kibana.

Since you're accessing Kibana behind a proxy, you'd need to bypass the proxy and see if the problem persists, i.e. compare the load times of
// through proxy
curl -v kibana_host/bundles/commons.bundle.js
curl -v kibana_host/bundles/kibana.bundle.js
// bypass proxy
curl -v localhost:5601/bundles/commons.bundle.js
curl -v localhost:5601/bundles/kibana.bundle.js
If the load time is lower when you bypass the proxy then you know it's not a Kibana issue but more with the way your proxy is configured.
UPDATE
Since we've narrowed this down to a proxy issue, try to update your nginx config with this
sendfile_max_chunk 512k
worker_processes 2
UPDATE 2
Try another modification of your nginx configuration:
proxy_buffering: off;

Tomcat 404 error, image js and css are not found

I used tomcat 7 for deploy my war file. It contains various images, css and js file.
I configure my tomcat on port 8080. Everything goes fine but I don't know why these content not serve by tomcat. It gives 404 not found error.
Directory Structure
And I hit this below url
http://localhost:8080/images/jackson2.png
When I put these images outside ROOT folder to inside webapps/examples/ then it works fine.
Now what is wrong with it ? It there anything I missed ?
I could not understand the issue ? Help me

Perhaps check that tomcat and/or the image files have the correct permissions set, I'm not too sure how to go about it on windows, depending on which version your running it could be a UAC issue, you can try looking here: https://www.mulesoft.com/tcat/tomcat-windows. You can try stopping tomcat, remove the work and temp directories, then starting tomcat.

Why is this simple CORS GET failing?

I have a server running apache. The .htaccess contains the following:
<IfModule mod_headers.c>
<FilesMatch "\.(eot|ttf|otf|woff|css)$">
Header add Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
Why is it that
$.get('https://www.sarahlawrence.edu/_assets/v6/fonts/otama-text-regular/otamatextregular.eot')`
works (try it in the console from any domain), whereas
$.get('https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css')
fails with this error:
XMLHttpRequest cannot load https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://whatever.com' is therefore not allowed access.
And how can I get it working?

The missing Header can be confirmed using curl:
curl -v https://www.sarahlawrence.edu/_assets/v6/fonts/otama-text-regular/otamatextregular.eot > delme.txt
curl -v https://www.sarahlawrence.edu/_assets/v6/lib/icons.data.svg.css > delme.txt
The regex should be happy with the filename so I expect that the problem is either because there is a conflicting configuration somewhere in the apache configuration.
Another diagnostic check would be to copy the failing file into the fonts directory and check whether the header is present - this will confirm that the regex or the filename isn't the problem but indicates that it is directory configuration related.
You have stated that there are no other .htaccess files in the document root or children ( this could cause the problem ) and the file is being served just without the headers.
My feeling at this stage is that this may be related to your mod_pagespeed which is disabled for lib/icons. It could even come down to the ordering of the modules being loaded.
Trivially I would first restart your apache just in case. Any caching or proxy infrastructure in between should be disabled. Next I would disable mod_pagespeed and see if the issue remains.
I would also check to see whether there is a block of configuration in either your httpd.conf or the virtual hosts configuration that is similar as it is possible that this is catching some directories and not others and that your .htaccess is not doing what is expected. As a further check I would try removing or temporarily renaming .htaccess ( to htaccess-removed or something similar ) to confirm that the URL request headers are no longer being included using the curl or other approaches to validating the CORS headers.
Probably not related however another thing I'd check is the permissions and ownership of the files and directories - thought worth mentioning just in case.
Also worth checking the error logs on restarting the apache and on making the requests as this may provide further insight.

What is the full path to your .htaccess file?
Ether your .htaccess file is not set up in a way to have it apply it's rules to files in the https://www.sarahlawrence.edu/_assets/v6/lib/ location, or there is another rule somewhere else superseding the rule you have shown above.

Javascript - ERR_CONTENT_LENGTH_MISMATCH

I'm making a basic jQuery playground site. I am getting Error: net::ERR_CONTENT_LENGTH_MISMATCH is happening on page load and the background images are not loading on the page.
The image in question is 300kb and is also dynamically changing. I am assuming this has something to do with file sizes, but I don't really know what.
HTML used originally:
<p style="margin:0px; padding:0px;">
<img id="background" src="/bg1.jpg" style='width:100%;' border="0" alt="Null">
</p>
JavaScript / jQuery used to change the background:
var changebg = function() {
if (myscore % 20 == 0) {
level++;
document.getElementById("level").innerHTML = "Level: " + level;
$("#level").fadeIn(1500, function(){$("#level").hide()})
backgroundindex++;
if (backgroundindex > 6) {
backgroundindex == Math.floor((Math.random()*6)+1)};
document.getElementById("background").src="/bg"+backgroundindex+".jpg";
};
}

I am getting Error: net::ERR_CONTENT_LENGTH_MISMATCH
Have a look at your server logs to determine what the real issue is.
For me the problem lay somewhere between nginx and file permissions:
tail -f /usr/local/var/log/nginx/error.log or run nginx -t to determine your conf location, where you could specify a custom log path.
refresh the asset in your browser, eg http://localhost:3000/assets/jquery/jquery.js
You may see something like this in the logs:
"/usr/local/var/run/nginx/proxy_temp/9/04/0000000049" failed (13:
Permission denied) while reading upstream for file xyz
Heres how I fixed:
sudo nginx -s stop
sudo rm -rf /usr/local/var/run/nginx/*
sudo nginx

Summary
Here is a more detailed explanation of what happened in my case. The selected answer here helped me solve my problem and this is basically a more detailed version of the selected answer on hows and whys!
Explaining Nginx Permissions
You can run nginx as a nobody user and that is the common practice in most sample configs. You will find this line at the top of your config:
user nobody;
It is however suggested that for your web-apps static contents, such as css, js, and image files to allow nginx access and cash it through bypassing your web-app
container. This the part of your config where it reads:
location ^~ /static {
alias /path/to/your/static/folder/;
autoindex on;
expires max;
}
This is the folder nginx needs to have access to.
On the other hand, there is nginx dedicated folder where in the above answer's case was in:
/usr/local/var/run/nginx/
In my case (CentOS) it was in:
/var/lib/nginx/
How can things go wrong?
In either of these cases you can break nginx:
1- Nginx runs as nobody but doesn't have the right access to your static folder.
2- Nginx runs as nobody but then runs as root to gain access to your static folder.
Solution
Best solution in my case was to change the permission of the nginx dedicated folder to match with my static folder. And then run nginx with as a user with the right access to both.

If you are using nginx + proxied server, try:
proxy_buffering off;
More infos: https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

My team saw this on a single javascript file we were serving up. Every other file worked fine. We originally saw net::ERR_HTTP2_PROTOCOL_ERROR. We switched from http2 back to http1.1 and then either net::ERR_INCOMPLETE_CHUNKED_ENCODING or ERR_CONTENT_LENGTH_MISMATCH. We ultimately discovered that there was a corporate filter (Trustwave) that was erroneously detecting an "infoleak" (we suspect it detected something in our file/filename that resembled a social security number). Getting corporate to tweak this filter resolved our issues.

In my case, I was using nodemon server.js in a next.js (server side rendered) app. By switching back to node server.js, the error disappeared.

I had the same error when building a rails app. I replaced an image with a different image and didn't change the file name, which threw the error above. Simply changing the file name made the problem disappear.

Another case where this error showed up for me : When trying to download a file from a node server with Angular 7, I had to redirect with window.location.href = <node_server_url> instead of the usual httpClient.get<any>(<node_server_url>).

I had this error when there ware no space left on web server disk.

simply fixing the permission of nginx folder fixed the issue.
chmod -R 755 /opt/nginx/

Here's another way to resolve this issue:
http://derekneely.com/2009/06/nginx-failed-13-permission-denied-while-reading-upstream/
NOTE: From a security point of view, I don't agree with the link where the author suggests to give 777 permissions to the folders. Give the minimum level needed to get the job done (in this case, 700 should be fine, you could even lower, though I did not try that yet).