Testing out connection reuse with http1.1 and http1.0 keep-alive on a service over HTTPS using the jersey client.
I have logging enabled on the jersey client:
Client client = ClientBuilder.newClient(new ClientConfig().register( LoggingFilter.class));
Also have SSL debugging enabled using the property option:
-Djavax.net.debug=ssl
This gives quite a lot of info, but jersey doesn't log the HTTP version used (i.e. if it's actually using HTTP1.0 or HTTP1.1). Is there some way to get this logged out?
Once I changed the javax.net.debug JVM option to 'all' the debug output included the data as well - including what version of HTTP was used in the requests:
-Djavax.net.debug=all
The output was not very pretty, but it worked.
Related
I have implemented Socket.io in the backend with netty SocketIO in java spring boot. And client connects to WebSocket using
ws://{server.ip.address}:5291/socket/?transport=websocket
http://{server.ip.address}:5291/socket/?transport=websocket
These both work as expected.
Now I have configured WebSocket on API gateway with HTTP integration.
And trying to connect using a gateway URL
wss://{app-id}.execute-api.{region}.amazonaws.com/{stage}/?transport=websocket
But it gives error: Execution failed due to configuration error: Unexpected response: HTTP/1.1 101 Switching Protocols
I have tried to diable proxy and enable Add Integration reponse option-> on Integration reposne add the response key '/101/' but nothing woked.
Also Route Response seems disabled.
Can Anyone tell me how to overcome from this issue and where I have to set respose code 101?
Do I need to change anyhting in Backend code for API gateway?
Folks,
We have a Java Applet communicating with the server through a BigIp Load-Balancer. The Java Applet is using an HttpURLConnection and the communication protocol is https.
The Load-Balancer implements a cookie based persistence policy to maintain session affinity.
This all works fine when the Java Applet using Java 1.5, 1.6 and early versions of Java 1.7.
Somewhere around Java 1.7.0_21 something went wrong with the Java Applet and now when we open HttpURLConnection for the 2nd time and on, the load balancer does not pass the request to the server but instead replies with the same response sent for the 1st request from the Applet as if thinking the request is for static content that can be cached.
Any ideas what has changed in recent versions of Java with respect to HttpURLConnection ?
You may want to check that you are properly negotiating an SSL connection. You can do this two ways: create an iRule to log to /var/log/ltm:
when HTTP_REQUEST {
log local0. “Requested hostname: [HTTP::host] from IP: [IP::local_addr]”
}
Turn on SSL debug logging:
tmsh modify /sys db log.ssl.level value Debug
If you are failing to negotiate SSL, you will not see anything logged from the iRule, but should have an answer as to why you are failing to handshake. Most often you need to adjust your cipher string.
We are building a mass mailing sending application in Java. Mail is being send by third party SMTP. After sending 400-500 mails tomcat6 service get stopped. Below is the error.
Proxy Error
The proxy server received an invalid response from an upstream server. The proxy server could not handle the request GET
/lin/Campaignn.jsp.
Reason: Error reading from remote server
Additionally, a 502 Bad Gateway error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at msizzler.com Port 80
But when we are sending from localhost I did not received any error. It send all the mails.
Please help me to sort it out this problem.
The HTTP 502 "Bad Gateway" response is generated when Apache web server does not receive a valid HTTP response from the upstream server, which in this case is your Tomcat web application.
Some reasons why this might happen:
Tomcat may have crashed
The web application did not respond in time and the request from Apache timed out
The Tomcat threads are timing out
A network device is blocking the request, perhaps as some sort of connection timeout or DoS attack prevention system
If the problem is related to timeout settings, you may be able to resolve it by investigating the following:
ProxyTimeout directive of Apache's mod_proxy
Connector config of Apache Tomcat
Your network device's manual
Add this into your httpd.conf file
Timeout 2400
ProxyTimeout 2400
ProxyBadHeader Ignore
The java application takes too long to respond(maybe due start-up/jvm being cold) thus you get the proxy error.
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /lin/Campaignn.jsp.
As Albert Maclang said amending the http timeout configuration may fix the issue.
I suspect the java application throws a 500+ error thus the apache gateway error too. You should look in the logs.
I had this issue once. It turned out to be database query issue. After re-create tables and index it has been fixed.
Although it says proxy error, when you look at server log, it shows execute query timeout. This is what I had before and how I solved it.
I had this problem too.
I was using apache as a reverse proxy for tomcat, my problem was associated with the return time of the response for "apache" proxy
I solved it like this:
open the "etc/apache/apache2.conf" and the ssl mod conf file "etc/apache/sites-available/000-default-le-ssl.conf" and add the following lines:
Timeout 28800
KeepAlive On
maybe this will help you
I am using Nginx to transform https to http from client to server.
I have an atmosphere configuration working well in websocket without this forwarding.
Now if I switch to https with Nginx in the middle
var request = { url: "https://localhost/writever/chat",
contentType : "application/json",
logLevel : 'debug',
transport : transport ,
enableProtocol : true,
fallbackTransport: 'long-polling'};
Websocket connection fails after a timeout and downgrades to long-polling.
Would you know if it is possible to have websocket working under these conditions?
By the way, latest nginx 1.3 supports websocket proxying - still in dev mode. Does it have an impact on an AtmosphereHandler if such a method is used?
it should not make a difference. But take a look at:
http://goo.gl/04g8F
You might want to add this header and see if that make a difference. I sincerely doubt, but try it.
-- Jeanfrancois
Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.
Note: The client works on my Windows workstation.
I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
the server returning with a 500 status code
On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".
My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.
Any help would be greatly appreciated...
UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..
Some references:
Java HTTP Authentication
Blog showing Java Authenticator Impl
A while back when i had this problem, i ended up using a scheme created by somebody else.
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
Worked for me when i had to get image files from and iis server with ntlm.
Snippet using the code above..
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
HttpClient client = new HttpClient();
client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
GetMethod get = new GetMethod(strImageFile);
get.setDoAuthentication(true);
client.executeMethod(get);