We are calling a web service (jaxws) running on JBoss 4 from one of our .NET, C#, web services clients. It is working just fine on our local network, but as soon as we connect to our VPN to test on the production environment it throws a 505 error (HTTP version not supported). On both our local and production machines, we have tested the services from a Java client while still connecting to VPN and it's working fine for the java client
Any hint regarding this issue?
I would guess that your production web server is not configured the same as your test web server; it is more restrictive and not allowing the HTTP version that you want. Ask the server admin for your production server what versions of HTTP are supported.
Another possibility is that on the VPN you have an intermediate proxy that is converting your request from one version of HTTP to another. Ask a network admin for help.
Related
In the client environment tomcat is running as a service with logon account as Local System Account. I have deployed a java based REST API client application in that tomcat. Every time the client is running its not able to set up connection with the destination.
In the client environment tomcat is running as a service with logon account as Local System Account. I have deployed a java based REST API client application in that tomcat. Every time the client is running its not able to set up connection with the destination.
There is absolutely no issue with the destination endpoint and the java code, as in other environments, that client is running fine in the tomcat.
Error that we are seeing is -- ConnectionTimeOut.
Account that the tomcat is running under in the client environment is -- Local System Account.
This is a huge road blocker and if anybody can provide guidance will be extremely helpful.
Error that we are seeing is -- ConnectionTimeOut.
Definitely it might be firewall issue. Your client is not able to connect to server, where your service is running. You need to ping from client machine to server where service is running. That will tells you whether Connectivity established or not.
We are using Apache Tomcat 8.0.18 as our web server.We are getting expected output when the client is sending about 5 to 8 concurrent requests.
But when the client is sending about 30 to 40 concurrent request , client is getting some unexpected error related to some packet loss while the request reaching the web server hosted in tomcat through Internet.
We are not facing the issue while we testing the application in our local environment.
We have examined the web server logs and we are seeing only part of the requests are reaching the web servers. We have installed the Tomcat 8.0.18 with default configuration.
Can any one please guide us whether we need to change any configuration in Tomcat level to resolve this kind of packet loss issue?
Thanks
Dinesh
I suggest that you should install a packet sniffer on the host where Tomcat is installed. Maybe the problem doesn't come from tomcat.
I am currently implementing a single signon solution for a customer that is based on Java, Tomcat and Kerberos.
Users are to access the URL of an intranet Tomcat application from their client browsers, the Tomcat application acquires the users' credentials via Kerberos and redirects them to the actual web application.
Our customer's environment is a typical mixture of a Windows AD server acting as the KDC and Linux Tomcat application servers. The SSO functionality is supposed to be used from both Windows and Linux clients. This is what appears to be different from most answers I can find on the net where people have Linux web application servers but only use Windows clients.
Now, in my local setup I get some strange behaviour. My development environment is a Tomcat 7.0.26 running from MyEclipse 8.6 under Windows 7. My test environment is a Tomcat 7.0.26 or 7.0.53 behind an Apache web server on a Centos 6 machine. I have set up the AD server correctly, generated the necessary keytab files etc. and everything is running smoothly in the development environment. I can access the Tomcat application from both Linux and Windows clients using IE and Firefox, Kerberos authentication proceeds and I get redirected properly.
When deploying the Tomcat application on the test server this keeps working when trying to sign on from Windows clients. However, when I try to access the test server from a Linux client (I have tried from Linux Mint 13 and Ubuntu 13.10), I get the following error:
javax.servlet.ServletException: GSSException: No credential found for: 1.3.6.1.5.2.51.3.6.1.5.2.5 usage: Accept
net.sourceforge.spnego.SpnegoHttpFilter.doFilter(SpnegoHttpFilter.java:233)
I have to admit that I do not properly understand this message. Does it point to a problem with the credentials supplied by the client or a problem with the application server negotiating with the KDC? I have done some research on this problem and have found out that the indicated oid 1.3.6.1.5.2.5 stands for GSS_IAKERB_MECHANISM and not GSS_KRB5_MECHANISM or GSS_SPNEGO_MECHANISM which I find strange. Also, nobody else appears to have exactly the same problem.
I have tried switching from MIT Kerberos to Heimdal Kerberos and back. I have tried Firefox and Chromium, on the application server I have switched between Tomcat 7.0.26 and 7.0.53, the problem still persists. I am using the latest spnego.jar.
Now: Calls from Linux to the Tomcat running on the Windows development machine succeed and calls from Linux clients to the Linux application server fail with the same error message for both browsers tried.
Any ideas on this one?
GSS_IAKERB_MECHANISM means that the client is not able to determine the realm/kdc to create a service ticket and asks the server to serve as an intermediate to the target KDC. Check Wireshark traffic. Your task now is to analyze why the client is not able to create a service ticket for that SPN. I have observed this issue on Heimdal on FreeBSD with Microsoft KDC.
So the problem ist not your Tomcat instance.
I can't find any documentation on how to run CAS SSO client application on HTTP. I've installed CAS server, it is running on HTTPS, that is OK. But I don't want my client applications to be running on HTTPS. The reason is because they are internal application, there is no need for them to run on HTTPS.
When I am trying to run my client applications on HTTP I am getting the exceptions of SSL handshake, because CAS expecting my application to be running over HTTPS.
Is this even possible to run client application integrated with CAS over HTTP? And if it is how to make this happen?
Specifications:
Tomcat 6.0.35
JDK 1.6
CAS 3.5.1
The CAS server knows the CAS client applications by the urls patterns defined in its back office and these urls patterns can be HTTP based.
I need to identify the remote ip and port of the clients that register to my service. Also, when the client web app goes down it un-registers itself from my web service.
i am using HttpServletRequest.getRemoteAddress() and HttpServletRequest.getRemotePort() to identify the clients.
but the problem is when i test on same machine i get different ports from the same client web app.
I am running JAX-WS web service on GlassFish and the Client Web App is also installed on the same container. Also, i am running Fedora 14 VBox VM.
Yes, that's correct, the port used by the connection is never guaranteed to be the same, and as you see, it varies.
The port is decided when the connection is made from the client to the server, and if multiple request are coming on multiple connections, multiple ports appear.