I have checked it at: http://www.ipchecking.com/ and they say they are the same. but when I visit each of them they are different
ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com - 404 error Problem accessing /. Reason: Not Found
54.206.38.225 - returns apache default page
ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com/jenkins - jenkins launchs
54.206.38.225/jenkins - not found
My understanding was that the host name should resolve to the ip address and thus they shouldboth take me to the same place?
What you are probably seeing is due to named based virtual hosts.
When your browser makes an HTTP request, it includes a header that says what host it is looking for. This allows a server to have more than 1 site hosted on a single IP address and port.
This can also allow a load balancer to redirect your traffic to different machines on its network for handling.
You can find more information at
https://en.wikipedia.org/wiki/Virtual_hosting
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Check this:
# curl -I -s http://ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com | head -3
HTTP/1.1 404 Not Found
Date: Tue, 05 Jan 2016 06:15:49 GMT
Server: Jetty(winstone-2.9)
# curl -I -s http://54.206.38.225 | head -3
HTTP/1.1 200 OK
Date: Tue, 05 Jan 2016 06:16:00 GMT
Server: Apache/2.4.7 (Ubuntu)
# curl -I -s http://ec2-54-206-38-225.ap-southeast-2.compute.amazonaws.com/jenkins | head -3
HTTP/1.1 302 Found
Date: Tue, 05 Jan 2016 06:16:18 GMT
Server: Jetty(winstone-2.9)
# curl -I -s http://54.206.38.225/jenkins | head -3
HTTP/1.1 404 Not Found
Date: Tue, 05 Jan 2016 06:16:28 GMT
Server: Apache/2.4.7 (Ubuntu)
From above commands (look at the HTTP response code closely),
When FQDN is used, the HTTP request is responded by JeTTy.
When IP Address is used, the HTTP request is responded by Apache.
Jetty is aware of /jenkins path
Apache is not aware of /jenkins path.
So this implies that, You have JeTTy acting as Reverse_Proxy/Load_Balancer. So the connection looks like this:
USER --> JeTTy --> Apache
Now, you need to figure out how JeTTy is configured for redirecting/denying requests. This link might be helpful.
However, Usually, I have seen that an application server is fronted by a web server as Reverse_Proxy/Load_Balancer. So, you might find that your setup looks like below:
USER --> Apache --> JeTTy
If this is the case then figure out how Apache is configured for redirecting/denying requests.
Related
I am using a consul client to deregister a service from my junit tests. I am using vert-consul-client . the consul version i am using is 1.11.1 . the service is not registered with the consul , but just testing what will happen if we try to deregister a service that is not registered.
from the logs i get this error
Status message: 'Not Found'. Body: 'Unknown service "BadService"'
strangely i dont get this error when testing with 1.10.6 consul version.
appreciate if you can help
thanks
strangely i dont get this error when testing with 1.10.6 consul version.
Consul recently changed the HTTP response code that is sent when an attempt is made to deregister a non-existent service.
Prior to Consul 1.11.0, and when ACLs were disabled, Consul would respond with a HTTP 200 response code and no response body when deregistering a non-existent service.
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 200 OK
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:07:35 GMT
Content-Length: 0
This behavior was changed in Consul 1.11.0 by PR hashicorp/consul#10632 wherein Consul now returns a HTTP 404 response code if a service does not exist, regardless of whether ACLs are enabled. (See diff of consul/agent/acl.go).
$ curl --include \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 404 Not Found
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: allow
Date: Wed, 05 Jan 2022 03:24:21 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
You're obviously not seeing an error in vertx-consul-client when communicating to Consul 1.10.6 because the HTTP 200 code indicates that the request was successful, whereas the HTTP 404 response correctly signals that the resource does not exist, and an error is correctly raised (see vert-consul-client/src/main/java/io/vertx/ext/consul/impl/ConsulClientImpl.java#L1320-L1333).
Interestingly in Consul 1.10.x, when ACLs are enabled on the cluster, Consul would reply with a HTTP 500 error code and a corresponding error message instead of the 200 response code. This is because when ACLs are enabled, the vetServiceUpdateWithAuthorizer function does not prematurely return (if authz == nil { return nil }) and proceeds with checking whether service exists, then raising an error because it does not (see consul/agent/acl.go#L96-L104).
$ curl --include \
--header "X-Consul-Token: $CONSUL_HTTP_TOKEN" \
--request PUT http://localhost:8500/v1/agent/service/deregister/test
HTTP/1.1 500 Internal Server Error
Vary: Accept-Encoding
X-Consul-Default-Acl-Policy: deny
Date: Wed, 05 Jan 2022 03:14:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8
Unknown service "test"
If you had tested 1.10.6 with ACLs enabled, you would've also received a similar error as you are seeing with 1.11.1.
I started experimenting with Traefik on Windows 10 and I need assistance with some very basic steps. Two are my main stumbling blocks: configuring Traefik natively on Windows 10 and http2 support.
1) Native Traefik on Windows
Following the instructions at https://docs.traefik.io/ I successfully managed to install the docker image of Traefik and see the dashboard on localhost:8080
However, when I try to start Traefik natively as "traefik -c traefik.toml" Traefik seems to "hang" no matter what I put in traefik.toml.
Can anybody show me a minimal Windows 10 configuration (.toml) to achieve what I achieve using the Docker version of Traefik?
2) HTTP2 support
Following the test shown at https://docs.traefik.io/#test-it, I execute this on the command line:
curl -v --http2 -H Host:whoami.docker.localhost http://127.0.0.1
but on the output I see:
< HTTP/1.1 200 OK
< Content-Length: 327
< Content-Type: text/plain; charset=utf-8
< Date: Wed, 05 Jul 2017 18:51:00 GMT
Does it mean that the response back is http 1.1 ?
Any help is much appreciated.
I am testing an API I have made using Springboot from my laptop (192.168.1.217:8080) and I am trying to get a cURL request via SSH from my Raspberry Pi.
Here is the error I am receiving when I try to send the request via port 8080 which it seems to not like:
pi#raspberrypi:~ $ curl -v 192.168.1.217:8080/api
* Hostname was NOT found in DNS cache
* Trying 192.168.1.217...
However cURL does work for the same IP but with port 80:
pi#raspberrypi:~ $ curl -v 192.168.1.217
* Rebuilt URL to: 192.168.1.217/
* Hostname was NOT found in DNS cache
* Trying 192.168.1.217...
* Connected to 192.168.1.217 (192.168.1.217) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: 192.168.1.217
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 30 Mar 2017 17:20:43 GMT
* Server Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.5.38 is not blacklisted
< Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.5.38
< X-Powered-By: PHP/5.5.38
< Location: http://192.168.1.217/dashboard/
< Content-Length: 0
< Content-Type: text/html
<
* Connection #0 to host 192.168.1.217 left intact
pi#raspberrypi:~ $
I've tried looking around but to no avail... anybody have any suggestions as to why I cannot find my own hostname in the DNS cache?
Cheers
No, Hostname was NOT found in DNS cache is not the problem. You can clearly see on the next line, in both examples, that after saying that curl is trying to connect to 192.168.1.217. Your problem is that nothing is answering on port 8080 on that IP address (while an Apache server is answering on port 80 there).
If you're getting a long pause and then a timeout rather than a quick "Connection refused", you almost certainly need to open port 8080 in the local firewall on your server machine.
curl without a protocol prefix presumes HTTP port 80.
To use another port, where it does not make that assumption, all you need to do is change your command's URL to be like this:
curl -v http://192.168.1.217:8080/api
Here is a decent article on the subject: Using CURL For Testing Web Applications
I have read about Web Hdfs in all this links
link1 link2 link3
checking with telnet - the port is OPEN
made the needed settings in cloudera ( virtual box) to make webhdfs enable
testing directly on cloudera works:
[cloudera#quickstart ~]$ curl -i -L "http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
HTTP/1.1 307 TEMPORARY_REDIRECT
http://quickstart.cloudera:50075/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&namenoderpcaddress=quickstart.cloudera:8020&offset=0
Content-Length: 0
Server: Jetty(6.1.26.cloudera.4)
HTTP/1.1 200 OK
Cache-Control: no-cache
Expires: Tue, 01 Dec 2015 14:08:07 GMT
Date: Tue, 01 Dec 2015 14:08:07 GMT
Access-Control-Allow-Methods: GET
Access-Control-Allow-Origin: *
Server: Jetty(6.1.26.cloudera.4)
trying directly on cloudera web browser also work for :
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN
I am able to send PING C:\Users\User>ping 10.0.0.88
Telnet working for port 50070.
But when trying this command outside the cluster it dosnt work (HOST)
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN"
more info
LISTSTATUS works from HOST
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFileop=LISTSTATUS&user.name=hadoop`
returns
{"FileStatuses":{"FileStatus":[
{"accessTime":1448982310759,"blockSize":134217728,"childrenNum":0,"fileId":26625,"group":"cloudera","length":47,"modificationTime":1448978300739,"owner":"cloudera","pathSuffix":"","permission":"644","replication":1,"type":"FILE"}
]}}
but op=OPEN from HOST
"http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN&user.name=hadoop"
returns
This webpage is not available
what could be the problem ?
It seems there is syntax problem in
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?`op=OPEN&user.name=hadoop`
Try
http://10.0.0.88:50070/webhdfs/v1/user/cloudera/testdir/testFile?op=OPEN
I have a problem with HttpFS service of hadoop.When i try to curl some resource:
curl -i http://192.168.4.180:14000/webhdfs/v1/user/hadoop/?op=LISTSTATUS
the response i get is:
HTTP/1.1 404 Not Found
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Mon, 17 Aug 2015 08:57:47 GMT
But when i try to do the same with webhdfs it works:
curl -i http://192.168.4.180:50070/webhdfs/v1/user/hadoop/?op=LISTSTATUS
HTTP/1.1 200 OK
and so on ....
Httpfs service is running on port 14000, i have checked it via nmap.
Any suggestions or ideas what might be the problem?
I meet the same problem. And solved by this link
In brief, you need to add the symbol link:
# Point to the 'webapps' in current.
cd /etc/hadoop-httpfs/tomcat-deployment
ln -s /usr/hdp/current/hadoop-httpfs/webapps webapps