When running a GET request for the root url of my deployment for the designated route, I get an HTTP Status 503 for /favicon.ico
http://blog-xyz-blog.1234.starter-us-east-1.openshiftapps.com/favicon.ico <- amended URL for privacy..
I then rsh onto the pod and curl the localhost url for the root url, and I get an HTTP 200, and same when I curl the /favicon.ico
I added the link to my index.html section, and the same issue occurring.
Any ideas why this is occurring?
Thanks
Related
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.
I have an IPFS file which I found inside my NFT, I am unable to get the asset inside that URL, can someone help.
This is the URL:
ipfs://QmcFAs7GH9bh6Q11bLVwd5J2c5EefadeL5Q8bZBLnMYYSJ/464.json
and I tried from browser with this URL:
https://ipfs.io/QmcFAs7GH9bh6Q11bLVwd5J2c5EefadeL5Q8bZBLnMYYSJ/464.json
I just shows a loading screen and a 404 http status is returned.
I have a page served via HTTPS. All content is public and no sensitive data is on this page. I also have resources (audio mp3) on a google cloud bucket which has no HTTPS support and is a subdomain (DNS C-NAME entry only), but is reachable via HTTPS but returns a Google certificate if accessed by https. Until now I had my server respond with a 302 redirect to my subdomain downgrading static mp3-resources from HTTPS to HTTP and it worked. See this request:
Request:
Request URL: https://x.com/q/ics/edit/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
Request Method: GET
Status Code: 302
Remote Address: 172.217.19.115:443
Referrer Policy: no-referrer-when-downgrade
Response:
content-length: 259
content-type: text/html; charset=UTF-8
date: Wed, 24 Jun 2020 05:42:46 GMT
location: http://subdomain.x.com/ics/_resources/r.6c19e2d99e220f648b3c1799ed05dc99.mp3
server: Google Frontend
status: 302
x-cloud-trace-context: 3086726898e017b2b99858fcea43c5e0
But suddenly Chrome started ignoring location: http: and instead resolves the HTTPS version, which causes ERR_CERT_COMMON_NAME_INVALID and this fails the download.
I know this can be resolved by using a load-balancer, but that would almost double our hosting costs (maintenance/setup/learning costs not included!) and we really do not need a load balancer with AppEngine classic.
The problem occurred a few weeks ago the first time, but went away within a day, but is persistent now!
Does anyone know why Chrome is interpreting the redirect this way? Is this required by any specification?
Update: The only solution I found so far is to downgrade the whole page with a redirect from HTTPS to HTTP. That is really a sad solution.
I'm on google cloud compute engine with a go webserver (no apache or nginx). I want to forward all http requests to https. My go code has ListenAndServe on port 8080 and the binary runs on port 3000 as https. This was accomplished using below.
gcloud compute forwarding-rules create pgurus --global --address
xxx.xxx.xxx.xxxx --ip-protocol TCP --ports=3000 --target-http-proxy
TARGET_HTTP_PROXY
Thanks in advance!
You can send back a 301 response when you receive an HTTP request. Google Cloud load balancer will set the X-Forwarded-Proto HTTP header with either the value HTTP or HTTPS. See this answer for details:
https://serverfault.com/a/735223
The HTTP response status code 301 Moved Permanently is used for
permanent URL redirection, meaning current links or records using the
URL that the response is received for should be updated. The new URL
should be provided in the Location field included with the response.
I am currently doing some debugging on my website which involves calling the facebook API. I've installed dnsmasq to work with my mac os X to redirect all request to facebook.com to 127.0.0.1
This is my entry in dnsmasq.conf:
address=/facebook.com/127.0.0.1
I also have /etc/resolver/com with nameserver 127.0.0.1
When I turn dnsmasq on, visiting facebook.com will result in a PAGE NOT FOUND error in chrome. This shows that my dnsmasq is working.
However, I noticed that chrome will redirect http://www.facebook.com to https://www.facebook.com due to HSTS. I went on to chrome://net-internals#hsts to delete facebook.com's entry.
The strange thing is, when I am debugging, I see that facebook.com is indeed returning 307 redirects for http://www.facebook.com (See image)
This is very strange because the domain facebook.com is currently resolved to be 127.0.0.1 on my computer! Furthermore, when I dig more into the request, I do see that the request is valid:
Where is this 307 redirect coming from if facebook.com is unresolvable?
307 is an internal browser based redirect for HTTP Strict Transport Security (HSTS). It does not come from the server - it's a fake response created by the browser.