I am not sure what happened because everything was working fine but now there is a weird bug on my app.
I had an app hosted on Modulus at www.raiseyourflag.com
I then created a version of it in React and Moved it to DigitalOcean at react.raiseyourflag.com to test and everything was working fine (all I did was import the Modulus DB into Compose.io)
Then I changed the nginx config to point to www.raiseyourflag.com and changed the DNS for www to point to the DO droplet and now all the images are getting a 404 but when I do something like CareerImages.findOne(); I get an Object and if I do CareerImages.findOne().url({stores: 'careerLargeImages'}) I get the url but when I go to it, I get a 404.
Is there any additional setup I should be performing on nginx to set so that /cfs files work.
I am using S3.
Also, now on localhost i get http://localhost:3000/cfs/files/careerImages/MoaFx95kSuZ3yTDvX/choreographer.jpg?store=largeCareerImages net::ERR_CONTENT_LENGTH_MISMATCH which wasn't happening before either :/
Related
I have gitlab running behind a nginx reverse proxy on a relative url (my.domain.com/gitlab/) in a docker container. I've migrated some of my projects from Github and everything seemed fine. However when I tried to see details for an existing issue, which was migrated with the project, the website didn't load. It looked like the reverse proxy was routing back to <server-ip-address>:<port> again, instead of the url. I also tested what happens when I create a new issue, because I thought maybe the migration didn't work, but it had the same effects. After a bit more testing I figured that typing in the issue-number in the url works though e.g. my.domain.com/gitlab/group-name/project-name/-/issues/4.
I'm really confused now, whether this is a problem with nginx or gitlab itself. Did anyone have similar issues?
Gitlab-Version: gitlab/gitlab-ce:14.10.0-ce.0
Nginx: nginx:1.21.6-alpine
I just downgraded Gitlab to version gitlab/gitlab-ce:14.9.4-ce.0 and it works. So I guess this is a problem with the other version and has absolutely nothing to do with docker or nginx.
I have deployed my nodejs based react application to digital ocean also i have used the cloudflare for ssl and dns hosting. My project has using google workbox and lru-cache. I have made nginx settings in the digitalocean ubuntu droplet.
Everything oke except the .jpg,.jpeg product images doesnt loading browser and giving me this error
iam showing in chrome like that
i will solve this error but i couldnt understand interesting with what
After some searching i concern about where is my image files in ubuntu and it has right permission to seen (chod x +R) for internet public users. Can they read my files. But i have suppresed with there is no any file in that directory. Couse ubuntu doesnt give me my process to write permisson when i uploading my jpg files with fs.sysnc
Edited:
After i seen that is interested with nginx settings which has looking another directory, i have corrected that and everything worked out!
I'm trying to deploy a symfony project, but something is wrong with the console (I'm on a shared hosting).
It worked just fine on localhost, but on the server, it seems to be looping, which I'm having trouble debugging, since I'm not really sure why this is happening..
Edit : Prior to uploading, I changed my DB parameters, renamed the web folder according to the name used by my host, allowed my IP in app_dev, and made sure everything worked fine under app.php on localhost. Once uploaded, config.php did not have any recommendations.
Can anyone please help?
Thanks
Here's a screenshot of firebug when I try to run the console
I have this site and I need to test it out locally to see if there is an issue with my php settings, anyways I tried to navigate to localhost with the port number localhost:portnumber
and that worked fine, but then I tried to navigate to my site localhost:portnumber/mysite and I get a 404 error and the in the the address i navigate to changes to localhost:portnumber/mysite
Why is this happening and what can I do to fix it?
Thanks
Because you are getting a 404 error, your server seems to be running but make sure the server is the one you have setup.
1st, have you tried using a simple html file? example: blabla.html on root, and typing: localhost:portnumber/blabla.html
If this is working, that means your server is running fine, you can also try with an Hello world php file if you wish.
In the case of wordpress, there is sometime a .htaccess file that uses url rewrite and it may remove your port number, you could try to test with a clean wordpress install first.
I've done a lot of searching and not found anything like this, but I might not be using the right terms. My problem is this:
On a Tomcat 6 server, I originally deployed a Spring Webflow app with a context root of fred - to access it people went to myserver.com:8080/fred
The Spring code in that app changed all requests to have /spring after the context root - so the URL above would become myserver.com:8080/fred/spring - and this would bring up the index page.
That was all fine & dandy.
I rewrote the app to use Spring MVC instead, for reasons too boring to mention here, and as part of this removed the code that performed the /spring piece.
I am now trying to deploy it to the same Tomcat instance. It appears to deploy fine (after undeploying the old one).
However when I try to hit myserver.com:8080/fred to get the index page, it redirects to myserver.com:8080/fred/spring, and naturally this fails as that URL is not supported.
I've checked my config within the WAR, and also scanned through the following places in Tomcat:
conf directory
conf/catalina and subdirectories
webapps and subdirectories
work and subdirectories
I can't see anything referring to this /spring url rewrite. It does deploy and work successfully on my local version of Tomcat.
Could anyone offer any suggestions? All help is appreciated.
Sounds like your browser cached the redirect. If your site at myserver.com:8080 used hard redirects (301 Moved Permanently) to send users from /fred to /fred/spring your browser will remember that the next time you access the application. Try emptying the browser cache and trying again.
That would explain why everything is dandy on your local machine