SSL/NPN will be handled via our loadbalancer (Haproxy), so I don't really need Jetty to do this for us.
But all the examples I can see on the web only show how to do this with SSL/NPN, not without.
Here's what I've attempted so far:
Server server = new Server();
HTTPConfiguration httpConfig = .... // set up some additional http config here
PushStrategey push = new ReferrerPushStrategy();
List<ConnectionFactory> factories = new ArrayList<>();
factories.add(new HTTPSPDYServerConnectionFactory(SPDY.V3, httpConfig, push));
factories.add(new HTTPSPDYServerConnectionFactory(SPDY.V2, httpConfig, push));
factories.add(new HTTPConnectionFactory(httpConfig));
ServerConnector connector = new ServerConnector(server, factories.toArray(new ConnectionFactory[factories.size()]));
connector.setPort(port);
server.addConnector(connector);
connector.start();
....
Unfortunately, it seems something is wrong, when I try to access the server via clients like curl or my browser they hang indefinitely. What am I doing wrong?
Thanks
When you configure a ServerConnector to speak clear-text SPDY, your clients must also speak clear-text SPDY.
If you use clients like curl or the browser, they don't speak clear-text SPDY. The clients will send a HTTP request which is not understood (the server expects SPDY), and that's why your connection "hangs".
Only Chromium/Chrome has a mode where you can make it speak clear-text SPDY, using the --use-spdy=no-ssl parameter as described here.
Therefore, if you're using clear-text SPDY there is no point in configuring multiple ServerConnectionFactory because there is no way to select one based on the protocol being negotiated, because there is no protocol negotiation.
The protocol negotiation only happens when using SSL+NPN.
Your code is basically correct (apart the unnecessary multiple ServerConnectionFactory) if you really want to setup a clear-text SPDY ServerConnector; this is an example of how the same is setup in the Jetty SPDY test suite.
Finally, see also the reference documentation about SPDY.
Related
I used the original jetty-proxy in Jetty 9, when the embedded start proxy server, after modifying the browser's proxy port, all access can be through the proxy server, I added my own filter in proxy server, add the way is:
ServletHandler handler = new ServletHandler();
FilterHolder fh = handler.addFilterWithMapping((Class<? extends Filter>) TLFilter.class, "/*", EnumSet.of(DispatcherType.REQUEST));
context.addFilter(fh, "/*", EnumSet.of(DispatcherType.REQUEST));
But my filter can only filter HTTP requests, but I can't filter HTTPS .
The development maintainers at jetty gave the results:
It is possible to deliver a CONNECT request to a Servlet service method, but it is ultimately futile to do so because it is impossible to handle a CONNECT inside a servlet. You don't really have access to the raw IO streams, only the HTTP content of the request/response. You can almost make his work, but never efficiently (no async IO etc.) So ultimately you will end up falling back to Jetty APIs anyway.
Also, why not just build on the support already provided by Jetty:
http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/proxy/ConnectHandler.html http://download.eclipse.org/jetty/stable-9/xref/org/eclipse/jetty/proxy/ProxyServlet.html
After installing WSO2EI-6.1.1 to migrate from my old WSO2DSS to EI, I was trying to setup a simple php wsdl soup client to call the "Version" service from php with a direct link to service wsdl and I'm getting the following error:
php code:
try {
$client = new SoapClient("http://server-ip:8280/services/Version?wsdl");
$response = $client->getVersion();
var_dump($response);
} catch (SoapFault $fault) {
echo $fault->getMessage();
}
error:
Fatal error: Maximum execution time of 120 seconds exceeded
Seems like the connection is timing out... I have tried to get the service wsdl with file_get_contents with the same result, timing out. well sometimes it works with a terrible loading time of like 90-100 seconds, but most of the times it times out.
$wsdl = file_get_contents("http://server-ip:8280/services/Version?wsdl");
var_dump($wsdl);
I have tested the link in browser and it is loading fine. Also tested with curl from linux command line and it loads fine there as well so the link is accessible.
curl -v http://server-ip:8280/services/Version?wsdl
So the timeout happens only when I try to retrieve the wsdl from within php. however if I download and save the wsdl file and pass the local xml file in php instead, then the service works fine and the version is fetched and displayed.
try {
$client = new SoapClient("Version.xml");
$response = $client->getVersion();
var_dump($response);
} catch (SoapFault $fault) {
echo $fault->getMessage();
}
So it seems like the problem is only fetching the wsdl directly from server in php and the rest of the communication between the server and the client is working fine.
after few hours searching I decided to try nhttp transport in transportReceiver configuration of axis2 instead of pass through transport and the problem is solved. however, reading the docs it is noted that the default transport is pass through and it is better in terms of performance compared to nhttp.
so is it a bug or something there causing the problem or am I doing something wrong and its possible to retrieve the wsdl directly from server within php while using the pass through transport?
Update:
when I use port numbers 9763 for http or 9443 for https instead of 8280 and 8243 to access services or service wsdl then I can access services or wsdl from php with no problems. So can anyone please explain to me whats the difference when using the port number 9763 or 8280 to access a service over http transport? Is it ok to use 9763 instead of 8280 to deal with services or to use 9443 instead of 8243? Is it still using the passthru transport when I use ports 9763 and 9443?
All WSO2 servers have two types of transports — servlet and passthrough (or nhttp). These are used for different purposes. Servlet transports are exposed over port 9443 and 9763 by default. This is the port used by admin services and the management console. The version service also uses the same port. For the services that you write and deploy, they are exposed over 8280 and 8243 ports. To answer your question, for this service you have to use 9763 or 9443 ports. And you will be accessing the Version service over servlet transport and not passthrough transport.
I'm new at using SoapUI, I'd like to know if my machine supports SOAP and in case yes, what I can use as an endpoint for my newly created SoapUI project.
My machine is a Windows-10, and on top of that I have installed Cygwin (enabling some UNIX features).
Does somebody know how I can retrieve a possible value for an endpoint for my SoapUI project?
Oops, from the comment I have the impression that my question is badly formulated: on my PC I have a server application, of which I don't know if it supports SOAP (I know it supports HTTP because I'm using localhost in a browser to access it).
However when I use localhost or 127.0.0.1 as an endpoint in my SoapUI project, nothing happens (I see no response and the request log stays empty), hence my question.
Per default, mostly no application will act as a SOAP prodiver, as it is much more complicated as REST/http for example.
If your application has the capability of a SOAP provider, it is usually SOAP over HTTP. But you need to know the correct endpoint url address.
Not only 127.0.0.1
Usually there is a servicename in the url (and you can also try to show wsdl with ?wsdl), like http://127.0.0.1/myapplication/myservice?wsdl
when setting up a new soapui project, you also have to provide the wsdl location
(http://127.0.0.1/myapplication/myservice?wsdl)
Regards, rka
We've developed a Proxy Service into WSO2 ESB which is an orchestrator, and calls multiple services aggregating the response.
How can I test each single step (or mediator) of the proxy flow, and how the system reacts to each possible situation (e.g. Success, Failure, Slow response time...)?
We are trying to mock the behaviour of each service called by the proxy (with Wiremock), for each step, but we are not able to dynamically change the endpoints (or the ports) pointed by each call.
Example:
Real service is listening on port 8280
Wiremock is listening on port 8281
We need to dynamically change the endpoint within the Proxy, to let it call the Wiremock service (8281) instead of the real one (8280)
If there are other ways to test, I'm happy to explore different solutions...
I am unable to get your question correctly... can't you in Your proxy service you mention the endpoint url with port as 8281...??
Finally found the solution to the problem.
Using the endpoints of the registry, you are able to get the resources from the registry, change them and update it.
For example you could do something like:
AutomationContext esbContext = new AutomationContext("ESB", TestUserMode.SUPER_TENANT_ADMIN);
String esbSession = esbContext.login();
ResourceAdminServiceClient resourceClient = new ResourceAdminServiceClient(esbContext.getContextUrls().getBackEndUrl(),
esbSession);
String endpoint = resourceClient.getTextContent("/_system/governance/endpoints/HelloService.xml")
.replace(":8280", String.format(":%s", port));
resourceClient.updateTextContent("/_system/governance/endpoints/HelloService.xml", endpoint);
I have an ASP.NET application which talks to a third-party SOAP web service. My application uses an ASMX client proxy (i.e. System.Web.Services.Protocols.SoapHttpClientProtocol). The third-party service uses WCF, although I don't expect that makes much difference.
I should note that we're using .NET 3.5 SP1.
We haven't customised the proxy or done anything unusual - we're just making standard web service requests and getting back the results. We have encapsulated the proxy reference within a using block so it will get disposed after the response is received.
We've been told that our application is behaving strangely in its use of TCP sessions. Instead of opening a new TCP session for each request from a new proxy instance (which is what I would have expected it to do), it's apparently keeping several connections alive and re-using them. This is causing some issues at the third party end, as they are expecting us to be using multiple sessions.
Is this a known behaviour for the SoapHttpClientProtocol client proxy? If so, is there any way we can override it so that each request results in a new TCP session?
Thanks,
John
See "Ways to Customize your ASMX Client Proxy". You'll see how to set the KeepAlive property of the HttpWebRequest used to make your requests.