Why does https://vivian-duong.gitlab.io work but www.vivian-duong.gitlab.io throw an error?
Here the domain is gitlab.io. But vivian-duong.gitlab.io is the sub domain. The www prefix doesn't work before sub domain. You have to add a CNAME to vivian-duong.gitlab.io to make it work.
Because there is no web server configured to listen for requests for www.vivian-duong.gitlab.io.
It's the same as if you requested non-existant-name.vivian-duong.gitlab.io. As far as the web server is concerned, it's a request for something it doesn't have.
Someone needs to setup the web server to listen and respond to requests for www.vivian-duong.gitlab.io.
DNS is resolving to the correct IP address, however the web server isn't configured to respond to that host header.
Related
I have added https binding to my SSRS but somehow it only work with hostname but not localhost and IP, http is working fine for hostname, localhost and IP.
HTTP
https://mypc:123/Reports -> Working
https://192.168.1.22:123/Reports -> NOT Working (Bad Request - Invalid Hostname)
https://localhost:123/Reports -> NOT Working (Bad Request - Invalid Hostname)
HTTP
http://mypc/Reports -> Working
http://192.168.1.22/Reports -> Working
http://localhost/Reports -> Working
Is the any misconfiguration?
Thanks.
Firstly, make sure you configure your https settings correctly in Report Server Configuration Manager. Second, your https port is 443 and not 123. Ex: https://localhost:443/Reports.
The reason might be that the HTTPS configuration was done using a certificate with CN=mypc; if you want to access the Report Server using IP or LocalHost(For some reason) then try creating a certificate with multiple CN values.
But I don't think its a valid use case as IP might change and localhost might not be accessible from clients.
I have a simple html page with video element that plays a video file of mp4 extension. I hosted the page in IIS 8. The MIME Type is configured correctly by default. If I browse using the server name it works fine but when I use the hostname the video does not play. The domain is from Godaddy and it is pointing to our public IP and then we have a load balancer that directs the requests to the two nodes servers.
Any ideas what could be the problem?
If you are able to resolve and access the server by server name then you must be calling the server from the internal network and are likely resolving to the internal IP address.
When you are calling the domain name then this will likely be resolving the public IP address from the DNS server where the A record is being hosted - GoDaddy.
ping <server name>
ping <dns name>
In order to test, please update your hosts file with the DNS name resolving to the internal IP address.
%WinDir%\System32\Drivers\Etc
<internal IP address> fqdns.com
If you try to call an external IP address being provided by a DNS server (GoDaddy) it is probably located on your firewall. Your connection will likely be dropped by the firewall due to anti-spoofing rules.
I have created a HTTP load balancer to basically redirect from port 80 to port 8080. The server on my instance is running on port 8080.
I can connect to the server directly but the LB is not able to connect to the instance, both accessing the LB's IP directly and also the health check always fails. The instance group the LB is using consist of just that single instance.
I read Google Compute Engine health checks failing
and the google-address-manager is running. However, when running ip route table list local there is no routing for my LB. The user in the above question is using Network load balancing and not HTTP load balancing (as I am) so I don't know if that is related?
Or perhaps it's related to a firewall? I have added my LB's ip address to a firewall rule that allows tcp:8080
Does anybode have any idea how can I fix this? I am not experienced with debian nor gcp.
Show I just try and run the route add command referenced in the above question? If so, how come the google-address-manager is not adding the route?
Thank you in advance!
You need to make sure that your port mapping on instance group is set to correct port, the 8080 in your case.
First, edit your instance group and change the port name and port to 8080:
Then, navigate to your http backend's settings and change the default port to the port name you've configured in your instance group.
Finally, make sure that your firewall rules allow access on port 8080 from 0.0.0.0/0 or at least from the IP address of HTTP load balancer (130.211.0.0/22)
I had the same issue and fixed it by adding a firewall rule for the health checker (which is not the same IP as your LB!). See https://cloud.google.com/compute/docs/load-balancing/health-checks?hl=en_US#http_and_https_load_balancing for instructions.
In my case, I did not configure the HTTP health check correctly.
I used "/" as path, but on my backend, "/" redirects to a login-page (HTTP 301), which responds with a HTTP 200.
The health check does not follow a redirect, every HTTP response code != 200 is assumed unhealthy (from Debugging Health Checks in Load Balancing on Google Compute Engine).
So, I changed my path to "/login", this fixed my issue.
I want to hotlink an image from a remote website. This works when I test in my local PC (Apache server), but doesn't work when I try from my website.
I am not an expert in this subject, but as I understand if hot-linking was blocked in the remote site, it should not work in my local server as well, right? In that case what might be the issue (my hosting provider is saying they don't have any issue)?
Let's play this through.
On your local server:
You make a request to 127.0.0.1 (or localhost) that returns some HTML with a hotlinked image to example.com.
The browser makes a subsequent request to example.com and sets the referer header to 127.0.0.1.
Now example.com has to determine whether the referrer is allowed to hotlink or not.
Since, for that server, example.com and 127.0.0.1 both refer to the same thing, namely the server itself, this looks like a valid request.
On your remote server:
Same as above, but replace 127.0.0.1 with your.favourite.url.
This time when the server validates the referrer, it will come to the conclusion that your.favourite.url and example.com do not refer to the same thing, and therefore block the image request.
This could be seen as a misconfiguration of example.com, since the referrer might not resolve to the same point from both client and server context.
If you access your local server via your local network IP (e.g. 192.168.1.42), then hotlinking should no longer work, unless example.com has a really graceful referrer policy, or happens to use exactly the same local IP as you.
It could also be possible to expose example.com's local IP by brute-forcing all local network IPs, though while that technically is an information leak, there's not much you can do with it.
I have a testapp consisting of an HTML5/WebSocket client and an HTTP/WS server. Both servers are in C#; the HTTP server is my own simple thing and the WS server is also homebrew based on concepts from http://nugget.codeplex.com/. HTTP server is listening on 0.0.0.0:5959 and WS server on 0.0.0.0:5960 (accept connections from any client, but on different ports).
My index.html includes some JavaScript that opens a WebSocket to 'ws://'+document.location.hostname+':5960/' (that is, to the same IP address that the webpage came from, but on port 5960). The WS server sends sample data every 100ms. All in all, it's a pretty straightforward demo.
I'm using Chrome 12.0 on Windows7.
I've found that the HTTP server works from any client, either a browser on my machine pointed to 127.0.0.1:5959 or localhost:5959, AND it works when any machine (mine or a remote machine... "remote" being a different PC on my desk :) hits my server machine's work-internal 10-net address 10.122.0.159:5959. Everything works as expected in HTTP land.
However, the WebSocket only works on 127.0.0.1 and localhost; remote machines can successfully fetch HTML from 10.122.0.159:5959 but the WebSocket will NOT connect to 10.122.0.159:5960. In fact, when I point my local browser to it's own 10-net address (10.122.0.159:5959) I get the same result - HTML loads but WebSocket does not connect.
Any ideas as to why this might be happening?
Does CORS require that the WS be using the same port as the HTTP request originated from? If so, is there a special exception to the rule for 127.0.0.1?
Many thanks,
-Dave
Update
It seems to be caused by a proxy server blocking ws:// requests. Our company employs a proxy server for content filtering and all the usual stuff, and our browsers are configured to use it.Chrome uses IE's proxy settings, and IE's default settings are for localhost to not use a proxy server. When I check the box to have local connections also use the proxy server, my ws:// requests to localhost get blocked. Conversely, when I uncheck the "use proxy server" box my server does rx the WS request. Similarly with the remote machine, if I turn off the proxy on the remote machine my server does rx the ws:// request.
So it's a proxy thing, not a CORS or socket thing, and now I'm off to explore proxy settings with our IT folks.
There is no WebSocket limitation on cross-origin except what is governed by the CORS security in the handshake.
It sounds like something is wrong with your WebSocket server and it is only listening on localhost for connections. I would add some debug output to the OnClientConnect routine in Nugget (WebSocketServer.cs) so you can see when socket connections happen. If you really think it isn't a problem with the server then I would suggest using wireshark and comparing the localhost connection to the remote connection.
Also, if you are using the SilverLight WebSocket prototype (README) in IE 9, then you are restricted to ports 4502-4534 for WebSocket connections. It's possible that for localhost this restriction is lifted.
It is/was indeed a proxy thing.
Rather than asking our IT folks to make changes (good luck with that, eh?) I simply turned off proxy for 10.122.0.159 ([Howto for IE/Chrome][1]). I briefly experimented with turning it off for the ws:// protocol but couldn't get it to work, so for now just opening that one IP address does the trick.