We Keep Coding

URLs don't work within production - return 404

This issue seems to be well documented but all solutions people suggest on posts don't work for me :/
I managed to fix urls giving 404 on my localhost by applying
--history-api-fallback
to the "scripts" package.json
however when I move the production over to my apache2 setup, any url I manually type or refresh returns 404, on site navigation works fine.
for example, http://www.craftmc.net/ works but http://www.craftmc.net/login returns 404, despite that url working if i navigate to it on site.
I saw a post saying use this .htaccess,
https://hastebin.com/alifavacil.apache
Sadly it didn't work. :/
navigation in question - https://hastebin.com/xevecefoda.xml

You need to configure Apache to serve your app on all URLs that it's supposed to handle.
By default, Apache will only serve your app when the user requests the specific path where the app is located, say for example www.example.com
If you now try to visit www.example.com/user/123, Apache will try to find a file named "123.html" inside the "user" folder. You have to tell Apache that what it should do is reply with your app even if the path requested by the browser doesn't actually point to your app within the filesystem on the server.
You can do this in several ways, but a common one is to use mod_rewrite. For example, you might try something along these lines:
DocumentRoot "/var/www/example.com"
AliasMatch "^/myapp" "/opt/myapp-1.2.3"
<Directory "/opt/myapp-1.2.3">
RewriteEngine On
RewriteBase "/myapp/"
RewriteRule "^index\.html$" "welcome.html"
</Directory>
For more information about mod_rewrite and the various directives it uses, refer to the documentation, and/or google.

Creating a NodeJS based web server to take advantage of HTTP2 on windows platform

I am using windows 2012 server and want to host some static HTML/CSS/JS/image files on a nodejs based web server. I do not want to use IIS as I want to take advantages of HTTP2 & want to push files from server to client. I looked at Using node.js as a simple web server which talks about how to create a node based webserver. Another option is to use http-server node package.
My question is:
These solutions are over two year old. Do we have a better option available now?
Does any of these two options supports HTTP2?
I would prefer using a existing node module rather then reinventing the wheel.

You could try NGINX, it can support HTTP/2. http://nginx.org/en/docs/windows.html
Run your node applications by using default node, nodemon, pm2...
Then use NGINX as a static web server and you can reverse proxy your node apps.

If you want to use Node then this article seems to cover the basics: https://webapplog.com/http2-server-push-node-express/ and it seems the node-spdy module is the best option (it includes support for HTTP/2 despite the name). There is a node-http2 module but it seems much less well maintained and doesn't support Express (the most popular HTTP framework for Node).
However, as discussed in the comments, while not the question you asked, I recommend running a traditional web server (e.g. Apache, Nginx or IIS) in front of NodeJS or any other traditionally back end server. While NodeJS is very flexible and most (if not all) of the functionality of a webserver can be added to it, a traditional web server comes out of the box with a lot of functionality and requires just configuration rather than programming and/or pulling in multiple other modules to set it up properly.
For just serving static files Node seems the wrong solution to me so, for the rest of my answer I'll discuss not not using Node directly for the reasons given above but instead using a front end webserver.
I don't know IIS too well but from a quick Google it seems HTTP/2 was only introduced in IIS 10 and, as far as I know, even IIS 10 doesn't support Push except through API calls so I agree with your decision not to use that for now.
Nginx could be installed instead of IIS, as suggested, and while it supports HTTP/2 it doesn't yet support HTTP/2 (though Cloudflare have added it and run on Nginx so imagine it won't be long coming).
Apache fully supports HTTP/2 including server push. Packaged windows versions of Apache can be downloaded from Apache Lounge so is probably the easiest way of supporting HTTP/2 push on Windows Server and would be my recommendation for the scenario you've given.
While I mostly use Apache on Linux boxes I've a number of servers on Windows and have quite happily been running Apache on that as a Service (so it automatically restarts on server reboot) with no issues so not sure what "bad experience" you had previously but it really is quite stable to me.
To set up Apache on a Windows Server use the following steps:
Download the last version from Apache Lounge.
Unzip the files and save them to C:\ (or C:\Program Files\ if you prefer but update all the config to change the default C:\apache24 to C:\Program Files\)
Edit the conf\httpd.conf file to check ServerRoot, DocumentRoot and any Directory values are set to where you want it (C:\Apache24 by default).
Run a DOS->Command Prompt as Administrator
In the Administrator CD to the Apache location and the bin director.
Run httpd.exe and deal with any error messages (note port 80 must be free so stop anything else running on that report).
Check you get the default "It works!" message on http://localhost/
Install Apache as a service by killing the httpd.exe process and instead running httpd.exe -install.
Start the Apache24 service and again verify you get the "It works!" message on http://localhost/
To add HTTP/2 and HTTPS (necessary for HTTP/2 on all browsers), uncomment the following lines from httpd.conf:
LoadModule http2_module modules/mod_http2.so
...
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
...
LoadModule ssl_module modules/mod_ssl.so
...
Include conf/extra/httpd-ssl.conf
Install a cert and key to conf/server.crt and conf/server.key - note Apache 2.4 expects the cert file to include the cert plus any intermediary certs in X509 Base 64 DER format so should look something like this when opened in a text editor:
-----BEGIN CERTIFICATE-----
MII...etc.
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MII...etc.
-----END CERTIFICATE-----
Where the first cert is the server cert and the 2nd and subsequent certs are the intermediaries.
You should make sure you're running good HTTPS config (the defaults in Apache are very poor), but the defaults will do for now. I've a blog post on that here.
Restart Apache in the service menu and check you can access https://localhost (ignoring any cert error assuming your cert does not cover localhost).
To add HTTP/2 to Apache
Edit the conf/extra/httpd-ssl.conf file to add the following near the top (e.g. after the Listen 443 line):
Protocols h2 http/1.1
Restart Apache in the service menu and check you can access https://localhost (ignoring any cert error assuming your cert does not cover localhost) and you should see h2 as the protocol in the developer tools of your web browser.
To use HTTP/2 push in Apache add the following to push a style sheet:
Header add Link "</path/to/css/styles.css>;rel=preload;as=style" env=!cssloaded
And you should see it pushed to your page in developer tools. Again, I've a blog post on that if you want more information on this.
If you do want to use Node for some (or all) of your calls you can uncomment the following line from conf/httpd.conf:
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
And then add the following config:
ProxyPass /nodecontent http://127.0.0.1:8000/
Which will send any of those requests to node service running on port 8000. Restart to pick up this config.
If your node service adds any HTTP headers like this:
link:</path/to/style/styles.css>;rel=preload;as=style
Then Apache should pick them up and push them too. For example if using Express you can use the following to set the headers:
app.get('/test/', function (req, res) {
res.header('link','</path/to/style.css>;rel=preload;as=style');
res.send('This is a test page which also uses Apache to push a CSS file!\n');
});
Finally, while on the subject of HTTP/2 push this article includes a lot of interesting food for thought: https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

I know this is a fairly old question, but I thought I would give an answer for those that come here looking for info.
Node now has a native http2 module and there are some examples on the web that show exactly how to implement a static web server.
NOTE: At the time of this answer Node 9.6.1 is current and the native module is still experimental
Example https://dexecure.com/blog/how-to-create-http2-static-file-server-nodejs-with-examples/
NOTE: I have no affiliation to the author of the example

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;

Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH

What does this error message mean and how do I resolve it? That is from console of Google Chrome v33.0, on Windows 7.
Failed to load resource: net::ERR_CONTENT_LENGTH_MISMATCH http://and.img.url/here.png
I'm trying to change the images' src attribute using jQuery. For example like this (simplified):
$('.image-prld').attr('src', someDynamicValue);
There are about 30 images on the page. And the above error is happening for random images every time when I reload the page. But sometimes it is working well for all the images, without any error.
When this error happens, the particular image is displaying like this:
However, when I open the link next to the error message on a new tab, the image is loading, which says me logically that the images is valid and it exists.

Docker + NGINX
In my situation, the problem was nginx docker container disk space. I had 10GB of logs and when I reduce this amount it works.
Step by step (for rookies/newbies)
Enter in your container: docker exec -it <container_id> bash
Go to your logs, for example: cd /var/log/nginx.
[optional] Show file size: ls -lh for individual file size or du -h for folder size.
Empty file(s) with > file_name.
It works!.
For advanced developers/sysadmins
Empty your nginx log with > file_name or similar.
Hope it helps

This error is definite mismatch between the data that is advertised in the HTTP Headers and the data transferred over the wire.
It could come from the following:
Server: If a server has a bug with certain modules that changes the content but don't update the content-length in the header or just doesn't work properly. It was the case for the Node HTTP Proxy at some point (see here)
Proxy: Any proxy between you and your server could be modifying the request and not update the content-length header.
As far as I know, I haven't see those problem in IIS but mostly with custom written code.
Let me know if that helps.

It could be even caused by your ad blocker.
Try to disable it or adding an exception for the domain from which the images come from.

This can be caused by a full disk (Ubuntu/Nginx).
My situation:
this error occured in Chrome with Nginx serving a static file: ".../static/js/vendor.c4ed7962fb4a63ad3c3b.js net::ERR_CONTENT_LENGTH_MISMATCH 200 (OK)"
root disk was full; after cleaning tmp files the error disappeared.
to prevent: make sure your disk remains clean ( a script such as this could help:https://crunchify.com/how-to-automatically-delete-tmp-folders-in-linux-automatic-disk-log-cleanup-bash-script/ )

In my case I was miscalculating the Content-Length that I advertised in the header. I was serving Range-Requests for files and I mistakenly published the filesize in Content-Length.
I fixed the problem by setting Content-Length to the actual range that I was sending back to the browser.
So in case I am answering to a normal request I set the Content-Length to the filesize. In case I am answering to a range-request I set the Content-Length to the actualy length of the requested range.

In my case I was modifying the request to append a header (using Fiddler) to an https request, but I did not configure it to decrypt https traffic. You can export a manually-created certificate from Fiddler, so you can trust/import the certificate by your browsers. See above link for details, some steps include:
Click Tools > Fiddler Options.
Click the HTTPS tab. Ensure the Decrypt HTTPS traffic checkbox is checked.
Click the Export Fiddler Root Certificate to Desktop button.

This is what worked for me.
proxy_buffer_size 1M;
proxy_buffers 4 1M;
I increased the size of the above parameters in nginix proxy.conf file.
Here, nginix is working as a proxy for my microservice-based applications.

It is definitely has to do something with disk space on your server
clearing the log folder worked for me.
follow these steps
1. go to nginx log directory
cd /var/log/nginx
2. delete all the older log
rm *.gz
3. emplty error log
truncate -s 0 error.log.1
4. empty access log
truncate -s 0 access.log.1

In my case it was a proxy issue (requests proxied from nginx to a varnish cache) that caused the issue. I needed to add the following to my proxy definition
proxy_set_header Connection keep-alive;
I found the answer here: https://stackoverflow.com/a/55341260/1062129

If this is related to docker, try stopping the erroneous container and starting a new container using docker run command from the same image.

If anyone struggle with that problem using docker + nginx, it could be permissions.
Nginx logs shown error:
2019/12/16 08:54:58 [crit] 6#6: *23 open() "/var/tmp/nginx/fastcgi/4/00/0000000004" failed (13: Permission denied) while reading upstream, client: 172.24.0.2, server: test.loc, request: "GET /login HTTP/1.1", upstream: "fastcgi://172.28.0.2:9001", host: "test.loc"
Run inside nginx container(path might vary):
chown -R www-data:www-data /var/tmp/nginx/

Running docker system prune -a did the trick for me. I did not have any luck rebuilding my containers or following #mrroot5's answer, although those would seem to achieve similar things.

In my case, I had to deactivate "All-in-One WP Migration" WordPress plugin.

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).