Express.JS net::ERR_CONTENT_LENGTH_MISMATCH for static file - node.js

I'm not able to charge one static file over express.js. Sometime, it work, sometime not.
The error i get is net::ERR_CONTENT_LENGTH_MISMATCH
Please understand that i use proxy but the error is occuring too when i was trying the request directly to the server.
So i have to reload the page several time, and sometime, it work

Related

node js rendered twice

i am using node js with template enjine ejs, i cant figure why my server is running every request from the browser two times, vecause when i do the same request from postman its only loaded one time, if i see network i get this
ass u can see the page home is loaded two times, so the req is make 2 times, where the server process times the same request and every thing , but why
after if i look at the request headers made by the browser i see something strange, that the header change its content, in my first(normal)request i get this:
but in the second request(the one that should'nt be made:
you can see that the accept parameter is different it looks like if he is requesting for an image in the static files , but i dont know what can be, first i thought was theb server was requesting the favicon.ico file, but its not because i already added a handler for that,
here i gonna let the whole project github code if someone need it and can help:
main files are appjs and server js, and req are handled by the routers folder and routers handle to their controller, is an MVC architecture
https://github.com/jazdevv/social-media-tw

Node JS {"type":"Buffer","data":[]}

I am making calls to a database through a node JS proxy and sometimes I get back the expected JSON data I am wanting and other times I get {"type":"Buffer","data":[]} as a response. I have never seen this response before and cannot find out why I am getting it sporadically.
For anyone seeing this in the future, my api was restarting when the request was made which resulted in that response. I fixed the issue with the api being down at the time of the request and the response is working properly now.

connection closed without response error because of external API call

I have a route where a user can post information for external webpage they want to save. Like the page title, URL, and image url for the page- similar to pinterest.
When my server gets this information (title, url, and image url), my server does a GET request for the image url to the external site. When my server gets the image data back, it crops and stores it on AWS and stores the link in a new mongo document with the other web page info and sends the response with this document back to the client.
As my production web app grows sometimes these image requests cause a H13 error on heroku. Even with a 6 second timeout set on the image request, I'm still getting a "connection closed without response" error in production maybe because other parts of the request are long too or it's a particularly busy moment in time on the site.
I feel like getting the image in the request and waiting for it to load in order to send a response to the client is maybe the wrong way to go about this. Is there a way to handle this request that will work better while my web app scales?
Not sure if this question doesn't belong on stackoverflow because maybe it's opinionated. But I'm not sure if there is a standard way to go about this and I'm just a newb.

Deployed angular project 'GET' request not working

I have an built angular project that I'm trying to run. I have copied the folder that I got from 'ng build' and put it in the folder where I have my back end code (used express). I'm running it on my laptop at port 3000.
While all the post requests in my application work fine, none of the GET requests seem to work.
Here is the exact error I'm getting.
If more information is needed to find out what I'm doing wrong, please ask.
Edit 1:
This is what I'm getting in the network tab. The response says html. But when I was working before deployment all my responses were coming as intended.
After looking into the images that you mentioned here, it look like that is has a http failure duing parsing in header:
Take a look here in order to resolve the same:
https://github.com/angular/angular/issues/18396
Thanks

facebook open graph debugger returning PARTIAL_FILE or operation_timeouted

I'm trying to setup a facebook share on https://donate.mozilla.org/en-US/thunderbird/share/
The og:url points to just /thunderbird which is the url I would want shared. Best I can tell the og tags are all there.
When I try to update the data on https://developers.facebook.com/tools/debug/og/object/
When I fetch new scrape information I get one of two errors. Initially, it'll take a long time then respond with a Curl Error : OPERATION_TIMEOUTED Operation timed out after 10000 milliseconds with {some number less than 10000} bytes received then subsequent fetch attempts respond with Curl Error : PARTIAL_FILE transfer closed with 17071 bytes remaining to read
We're using AWS Cloudfront and nodejs with hapijs
It responds with a 206 partial content, which, should be fine. The og tags are all in the beginning of the file.
I found this: docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html
There it says a range request is used to get the file in chunks, not to get just the part of the file and give up. So maybe that's causing unexpected behavior. Maybe cloudfront is sending it back in chunks, and facebook stops listening after the first response? I dunno. Just trying to find a theory that fits the facts.
We already have a working share for donate.mozilla.org/en-US/share/ but that might be old data from when we were not using hapijs and instead using expressjs which I don't think was supporting range requests and would instead return a 200.
I'm mostly a front end dev, so a lot of this is out of my comfort zone but I have already learned a lot :)
Edit: I also want to point out we use Heroku for hosting, and if I setup a test with just heroku and without cloudfront: donate.mofostaging.net/en-US/thunderbird/ it fetches the tags successfully. So I suspect it's a bug when facebook and hapijs interact with cloudfront.

Resources