My java program is hitting "http://url:port" kind of url to fetch some data. On my local windows machine deployed on tomcat 6, it is working fine. But on production which is a linux machine having tomcat 6 on it, it gives me connection timeout.
Ironically, if I hit the URL without port number, it will successfully bring me the output but not with port. Not finding any clue, please help.
The snippet of code I am using to connect and fetch data is:
HttpClient httpclient = new DefaultHttpClient();
HttpGet httpget = new HttpGet("59.162.167.36:80/api/…");
httpget.setHeader("User-Agent", "UserAgent: Mozilla/5.0");
HttpResponse response = httpclient.execute(httpget);
HttpEntity entity = response.getEntity();
One obvious possibility is that a firewall in front of your production machine is blocking access to that port. Check the firewall.
The answer is straightforward: On production you don't have that port opened, contact the administrator, or the hosting and issue your problem. Of course they will confirm my thesis.
Almost certainly your hosting provider implements a firewall of some description in the data center. This is common practice. Send them a message asking if port X is blocked, and if so can they open it.
Related
One of our devs reported the following error.
HttpGet foo = new HttpGet("http://www.example.com/path/to/file.xml");
works fine.
However, if the port is specified,
HttpGet foo = new HttpGet("http://www.example.com:80/path/to/file.xml");
the server returns a HTTP 500 error.
I've already verified that the website runs on the standard HTTP port 80. What could be the reason of this behavior? It looks like it's server side, as both lines of code work fine towards other websites.
A look into the server's log should bring up more information what exactly is going wrong there (status code 500 means that the server ran into a problem) but my guess is that there is some kind of script configured behind the URL that processes that value of the HTTP-request-header Host, doesn't expect the port-specification and runs into an error because of this.
Another reason might be a proxy between you and the server that ran into an error but I found that more hard to believe than the above theory.
Please provide the error-log of the server in order to be able to say more about this.
This is a question regarding an exception that is occurring in my code which makes a call to an https server.
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
It internally uses an instance of CloseableHttpClient to execute the PUT call.
Also, this code is a functional test that would be running on a remote machine as a CI job. I have seen some solutions with the SSL certificate error that mention how we can disable the SSL certificate validation in Java or add the certificate in the local JVM, one of them being here -
'peer not authenticated' SSL certificate error usng DefaultHttpClient
Unfortunately, it doesn't seem to be working as this is a remote machine and we cannot import certificates into that machine.
String endPoint = "https://" + hostName + ":" + port + "/v1/service/data/put";
endPoint is set in the code that is called from a jar. So, there is no scope that we'd be able to change it either.
If I am running the code that makes a PUT call to the endPoint from a standalone class (through the main method), it seems to be running fine, returning a 200/OK. Currently, the exception occurs if it is being run as a TestNG class from the .xml file.
The code added as a Github gist is here.
Let me know if you need more details.
there's a lot going on there and most of it isn't really related to the problem (the caching, for example or the other boilerplate code to set up the call).
what i usually do in this kind of situation is reduce your problem to a smaller and smaller chunk of code that can still reproduce the problem. for ex, using these HttpClient components, can you make any SSL call? try this code, which requires HttpClient 4.4 and will work on sites that don't have valid certificates:
CloseableHttpClient client = HttpClients.custom()
.setSSLContext(sslContext)
.setSSLHostnameVerifier(new NoopHostnameVerifier())
.build();
HttpGet httpGet = new HttpGet(<your https URL here>);
httpGet.setHeader("Accept", <whatever appropriate for URL above>);
HttpResponse response = client.execute(httpGet);
System.out.println(response.getStatusLine().getStatusCode());
As it was mentioned in the question, the code works fine if it were running in a standalone class, through the main method.
I was able to resolve the issue by placing my code in a static block. It might be related to the certificates being disabled during class load and thus, works fine now.
I am trying to build a website parser for one of our internal websites (accessible only from the company network - we get on the network through Cisco AnyConnect VPN).
I can access the site fine in any browser, but not using HTTP requests. Windows network and sharing center shows that I have two active networks:
The actual internet connection
The company network (without internet access).
Default HTTP client gets time out as I suppose it makes a request using the actual internet connection (and the website is not accessible to public), but using this code:
HttpParams params = httpClient.getParams();
params.setParameter(ConnRoutePNames.LOCAL_ADDRESS, InetAddress.getByName("10.x.x.x"));
I get the following error:
I/O exception caught when connectiong to /10.x.x.x -> {s} -> https://zzz.com:443: Network is unreachable: connect
Also, might be a stupid test but I have done a HTTP request to a "what is my ip" site and the IP is shown as my Wifi IP not the IP through VPN (which I get when I open browser and browse to a "what is my ip" website). Same thing (wrong IP) when I try this using a gui-less browser (Jaunt or HTMLUnit).
Please advise if any fixes for this.
ConnRoutePNames appears to be deprecated. See if the following works (I haven't tested):
HttpHost proxy = new HttpHost("10.x.x.x", 80);
HttpRoutePlanner routePlanner = new DefaultProxyRoutePlanner(proxy);
CloseableHttpClient httpclient = HttpClients.custom()
.setRoutePlanner(routePlanner)
.build();
I am running two web application using IntelliJ. Both are running on http port 8080 and for one I have changed jmx port to 9099. Issuse is when I try to call another app using httpget HttpGet httpGet = new HttpGet(http://localhost:8080/b-app); from the a-app, http request never hitting http://localhost:8080/b-app. Do I need any specific configuration in intelliJ for it?
Thanks for the help
I have a bit of Java code to download url data that is plagued by the error in the title. Sometimes it works, most time it fails. Has anyone come across this:
URLConnection urlConnection = url2search.openConnection();
urlConnection.setRequestProperty("User-Agent","Mozilla/5.0 ( compatible ) ");
urlConnection.setRequestProperty("Accept","*/*");
urlConnection.setDoInput(true);
urlConnection.setDoOutput(false);
try{
reader = new BufferedReader(new InputStreamReader(urlConnection.getInputStream()));
}catch(Exception r)
{}
Now it fails consistently at the reader line with:
java.io.IOException: Server returned HTTP response code: 520 for URL:
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
I can copy the url in to the search bar and it works fine. And as yet my web research on this topic has proved fruitless. Any suggestions?
An HTTP error code between 500 and 599 indicates a server failure. It could be at the requested document's origin server, or at a proxy server between the client and the origin server.
Code 520 itself is not documented by any of the HTTP specifications, so its specific meaning is unclear. If that code is being generated by a CloudFlare reverse proxy between your client and the origin server, however, then it signals a generic, unspecified connection error between the proxy and the origin server.
Any way around, the problem is basically external to your client. It may be that there is something about your request properties that tends to cause the server chain to fail as you observe it to do, but to debug it you need either to analyze the server logs and software, or else to reverse-engineer its behavior. If the problem is not exhibited in conjunction with your browser, then you could consider capturing the request/response involving your browser to see how it differs from the request/response involving your Java client.
Try bringing your user agent string up the latest.
See here: https://www.whatismybrowser.com/guides/the-latest-user-agent