We Keep Coding

Dependency uses outdated URL

I'm trying to clone and build a GitHub repo using Bazel, but a dependency requires an old verson of zlib via an outdated URL. I've already spent a few hours trying to do things like messing with the /etc/hosts file and running a web server to get it to work. I've gotten zlib.net to point to localhost, then running a web server on localhost:80 with zlib at the correct path, but that's not working, since the request is timing out.
I've googled it and only about 3 remotely relevant results have popped up, none of which are helpful.
How do I get it to build?
This is the error:
Error in download_and_extract: java.io.IOException: Error downloading [https://zlib.net/zlib-1.2.11.tar.gz] to /private/var/tmp/_bazel_user/37df51594c7eac8a62dd677a22c5514b/external/zlib/temp16216011345324291299/zlib-1.2.11.tar.gz: GET returned 404 Not Found

It is timing out because the request uses HTTPS, which is port 443, not HTTP on port 80. You can use a similar approach to what you are doing (with the hosts file) but just run a HTTPS server on port 443.
This can be achieved using tools such as ngrok and your current localhost web server.

Tomcat receives HTTP 400 but CURL receives 200

I have a very strange scenario where, in a Linux server, CURL successfully retrieves a response from a web service. When that same request is issued by Tomcat on the same linux server used for the CURL command, for some reason Tomcat receives a 400 status code, which prevents me from doing our business logic.
Flow with CURL:
CURL issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
CURL receives the correct data and 200 status code...
Flow with Tomcat:
Tomcat issues request to Service A using Proxy A
Service A retrieves the data we need and returns it, as well as a 200 Status Code
Tomcat receives a 400 status code and is not able to receive the correct data...
What could be causing this problem? Tomcat and CURL are using the same proxy and are in the same linux server... even the service is able to fetch the data successfully and return it to both. Only in the case of tomcat, the service is throwing this error after trying to write the data in the response:
2021-03-10 21:49:36.908 WARN 90623 --- [https-jsse-nio-8123-exec-10] .w.s.m.s.DefaultHandlerExceptionResolver : Resolved [org.springframework.http.converter.HttpMessageNotReadableException: I/O error while reading input message; nested exception is org.apache.catalina.connector.ClientAbortException: java.net.SocketTimeoutException]
Tomcat closes the socket because it sees a 400 response code, and doesn't even try reading the bytes from the response when I do con.getInputStream(). I don't really know where that 400 Status code is coming from.
Any help is appreciated. Thanks.
UPDATE 2021/03/11:
One thing I forgot to mention is that, Tomcat is able to perform other requests to that same service. The main difference here is the size of the response. It timesout when trying to read this large response, in comparison to other smaller responses we get.
UPDATE 2021/03/16:
After investigating deeper on what is happening I found out that, whenever I issue the request with Java, for some reason it timesout at exactly 2 minutes. That doesn't happen with CURL, only with Java. Is there anything I may be missing? I have already added these to my code:
JVM Arguments:
-Dsun.net.client.defaultReadTimeout=6000000 -Dsun.net.client.defaultConnectTimeout=6000000
Java code
con.setReadTimeout(Integer.MAX_VALUE);
con.setConnectTimeout(Integer.MAX_VALUE);
con.setDoOutput(true);
con.setDoInput(true);
I'm using an HttpURLConnection object.

http.converter.HttpMessageNotReadableException
The message that your tomcat sends to the service can not be read. Something happens with the message that your tomcat sends to the service. Does it have a json body included? If yes check that model class how it is serialized.

http.nonProxyHosts ignored on localhost only

I run a proxy on localhost:2080 for debugging purposes. I can see trafic going through my proxy using either:
curl http://localhost:8888/stuff --proxy localhost:2080
curl http://some.server.com:8888/stuff --proxy localhost:2080
Using a Spring application, or a bare bones HttpURLConnectionExample Java application, I see requests go through the proxy when I call some.server.com, but never on localhost, even though I set http.nonProxyHosts to a random value (to avoid the default of localhost).
I made sure my JVM arguments were taken into accounts by adding the following code:
System.out.println("java.version="+props.getProperty("java.version"));
System.out.println("http.proxyHost="+props.getProperty("http.proxyHost"));
System.out.println("http.proxyPort="+props.getProperty("http.proxyPort"));
System.out.println("http.nonProxyHosts="+props.getProperty("http.nonProxyHosts"));
That produces the following output:
java.version=1.8.0_131
http.proxyHost=localhost
http.proxyPort=2080
http.nonProxyHosts=dummy.snafu.com
https.proxyHost=localhost
https.proxyPort=2080
https.nonProxyHost=dummy.snafu.com
Testing 1 - Send Http GET request
Sending 'GET' request to URL : http://localhost:8888/stuff
Response Code : 200
hello
Why are HTTP requests to localhost not going through my proxy when run with the following JVM arguments?
-Dhttp.proxyHost=localhost
-Dhttp.proxyPort=2080
-Dhttp.nonProxyHosts=dummy.snafu.com

This is a limitation of DefaultProxySelector, It always appends local Uris(localhost, 127.*, etc) to whatever you configure as nonProxyHosts, essentially bypassing proxy for all local Uris(localhost|127. *|[::1]|0.0.0.0|[::0]). Fortunately, there is a workaround by creating your own proxy selector and registering it as default.

Https web service call failure

We have implemented webservice call using JAX-WS RI 2.1.6 in JDK 6 now problem comes when we enable https webservice call stops reaching server and java reports following error,
javax.xml.ws.WebServiceException: java.io.IOException: Async IO
operation failed (3), reason: RC: 55 The specified network resource
or device is no longer available.
Now I have tested this within SoapUI and response from the service is received there.
Looked into various solution where it tells us to provide timeout settings but nothing seems work.
#WebEndpoint(name = "RulesSoap")
public RulesSoap getRulesSoap() {
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.connect.timeout", 1000);
((BindingProvider)super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class)).getRequestContext().put("com.sun.xml.internal.ws.request.timeout", 1000);
return super.getPort(new QName("urn:decision:Rules", "RulesSoap"), RulesSoap.class);
}
And just for information JAX-WS implementation is following few simple lines,
of course we submit all necessary data into respective stubs and all but I am not submitting here because our http calls are getting through,
Rules rules = new Rules(new URL(url), new QName("urn:decision:Rules", "Rules"));
RulesSoap rulesSoap = rules.getRulesSoap();
CorticonResponse response = rulesSoap.processRequest(request);
Note : Our application server WebSphere Application Server and Version 7.0.0.19
Thanks in Advance.

After lots of efforts we resolved this. I will provide steps if anything related to this happens how to find root cause,
Step 1 :
First of all we enabled soap tracing in WebSphere Application Server by following setting,
Admin Console > Servers > Server Types > WebSphere Application Servers >
{your server} > Troubleshooting > Change Log Detail Levels > Runtime
In run time please put this , *=info: com.ibm.ws.websvcs.*=all: org.apache.axis2.jaxws.*=all
This step will create trace.log file in your logs folder.
Now any web service request which goes out of your server will add logs to this file and necessary props like endpoint, request, response etc.
Step 2 :
Reading this trace.log file we found following endpoint,
PropertyValid 1 org.apache.axis2.jaxws.client.PropertyValidator validate validate property=(javax.xml.ws.service.endpoint.address) with value=(http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0)
HTTPConnectio 3 resetConnection : http://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0 Persistent : true
Now if you notice here that our soap has endpoint address javax.xml.ws.service.endpoint.address where protocol is still using http which causes to fail ssl handshake.
Step 3 :
Solution for this is to override endpoint inside your soap stubs which can be implemented by adding following line,
RulesSoap rulesSoap = rules.getRulesSoap();
((BindingProvider)rulesSoap).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://uxm.solutions.lnet.com:9445/axis/dswsdl/Rules/1/0");
Conclusion :
So here is what i think even we pass https url while we are creating objects but still does not take this https url on runtime, to me this looks like stubs creation issue with JAX-WS.
Thanks.

What protocol /ciphers are you using? You have mentioned there is connection to webservice on WAS7 with JDK6 and Java 6 does not support TLS1.2 (and TLS1.1 only from certain fixpack).
See this:
How to use TLS 1.2 in Java 6

ERROR: Running application failed - Spring boot + Boxfuse/AWS

I am trying to run my Spring boot application on AWS using boxfuse.
I have followed the following tutorial from Spring (section 54.4) and the Get Started from Boxfuse aswell.
When i run the following command
boxfuse run target\digigram-0.1.0.jar -env=prod
i get the following lines
Waiting for AWS to boot Instance i-74fe7fc8 and Payload to start at http://52.28.94.159:8080/ ...
WARNING: Healthcheck (http://52.28.94.159:8080/) returned 404 instead of 200. Retrying for the next 120 seconds ...
Terminating instance i-74fe7fc8 ...
And it ends with
Destroying Security Group sg-0ed6f667 ...
ERROR: Deployment of pantera160/digigram:0.0.0.1453900589995 failed in prod:Payload of Instance i-74fe7fc8 came up at http://52.28.94.159:8080/
with HTTP 404 (expected 200) => ensure your application responds with an HTTP 200 at http://52.28.94.159:8080/ or adjust the healthcheck configuration (healthcheck.path, healthcheck.timeout, ...) to fit your application
ERROR: Running pantera160/digigram:0.0.0.1453900589995 failed!
I don't understand where the problem lies. Do I have to change something in AWS or in my application or...
Any help would be greatly appreciated.
NOTE:
I am running on a free plan for AWS, might this be the problem?

Boxfuse ensures that a correct version of your app stays up and running and does not get replaced by a bad one. Only when a new version does pass Boxfuse's health check, does Boxfuse reassign it the application's Elastic IP. Once that is complete Boxfuse terminates the instance of the old version.
To verify that a new version of your app comes up correctly Boxfuse expects the new version's instance's healthcheck path to return HTTP 200.
The default healthcheck path for a regular Spring Boot application without the actuator is /. Your app currently answers 404 there instead of 200.
You have a number of options to fix this:
Add a controller to your app mapped to / that returns HTTP 200 when your app comes up correctly.
Change Boxfuse's healthcheck.path to a different path that does indeed answer HTTP 200 when your app comes up correctly.
Disable Boxfuse's health checks by setting healthcheck to false (not recommended as this effectively prevents Boxfuse from checking whether your application came up correctly)
Pick either one of these options and your app will come up correctly as you would expect.