We're trying to use Axis2 to call a web service that cannot use HTTP/1.1 (default transport protocol in Axis2). Is it possible to programmatically set Axis2 to use HTTP/1.0? I know that this can be done with a configuration file, but in our case API use would be much better solution.
Here's some code that we're using:
ServiceClient client = new ServiceClient();
Options opts = new Options();
opts.setTo(new EndpointReference(endpointAddress));
client.setOptions(opts);
I tried to figure out if I could somehow use the Options object to set transport protocol, but didn't yet succeed. :(
Ok, I was a bit trigger-happy with sending the question... I just find out from the Axis documentation that you can set the HTTP version with the following code:
options.setProperty(org.apache.axis2.context.MessageContextConstants.HTTP_PROTOCOL_VERSION,
org.apache.axis2.transport.http.HTTPConstants.HEADER_PROTOCOL_10);
and as the MessageContextConstants.HTTP_PROTOCOL_VERSION seems to be deprecated, I can use the following:
opts.setProperty(HTTPConstants.HTTP_PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_10);
Related
I'm trying to create a serverless function for Kong for authentication purposes. I'm required to use a client certificate to authenticate with the remote service that we have to use. I can't seem to get this working and there appears to be no clear documentation on how to do this. I've tried pintsized/lua-resty-http, ngx.socket.tcp(), and luacurl (failed to build) without success. I'm using the newest version of Kong in an Alpine Linux container in case that matters.
What is the best way to do this? Right now I'm considering simply calling curl from within Lua as I know that works, but I was hoping for a better solution that I can do with just Lua/OpenResty.
Thanks.
UPDATE: I just wanted to add, just in case it helps, that I'm already building a new image based on the official Kong one as I had to modify the nginx configuration templates, so installing new software into the container is not an issue.
All,
Apologies for the ugly code, but it looks like a found an answer that works:
require("socket")
local currUrl= "https://some.url/"
local https = require("ssl.https")
local ltn12 = require("ltn12")
local chunks = {}
local body, code, headers, status = https.request{
mode = "client",
url = currUrl,
protocol = "tlsv1_2",
certificate = "/certs/bundle.crt",
key = "/certs/bundle.key",
verify = "none",
sink = ltn12.sink.table(chunks),
}
If someone has a better answer, I'd appreciate it, but it's hard to complain about this one. The main issue is that while this works for a GET request, I'll be wanting to do POSTs to a service in a future and I have no idea how to do it using similar code. I'd like one libary/API that can do any type of REST request.
This blog got me on the right track: http://notebook.kulchenko.com/programming/https-ssl-calls-with-lua-and-luasec
I'm attempting to strip TLS SNI headers. How can I manipulate HTTPS extensions using Fiddlerscript?
Unfortunately, the .NET Framework does not expose the level of granularity you require for the SslStream class (and Windows itself doesn't make it easy either). The only way you can achieve what you're looking for with Fiddler today is to disable TLS1 and offer only Ssl3.
To update your FiddlerScript, click Rules > Customize Rules. Scroll down to the Main() function and add the following line within the function:
CONFIG.oAcceptedServerHTTPSProtocols = System.Security.Authentication.SslProtocols.Ssl3;
I am using Apache Jackrabbit Webdav library for svn checkin operation.
I am using MAKActivity method to start the transaction.
But I dont know how to add commit message. Following is the code
RandomStringGenerator rsg = new RandomStringGenerator(32);
String random = rsg.nextString();
String url = getRepoAddress() + "!svn/act/" + random;
MkActivityMethod activityMethod = null;
try
{
activityMethod = new MkActivityMethod(url);
client.executeMethod(activityMethod);
}
catch(Exception e)
{
e.printStackTrace();
}
This code executes successfully but I dont unserstand how to write log message in this.
Any help will be appreciable.
First of all I'd suggest that you not reinvent the wheel that's already been done twice now and instead using a library that knows Subversion's DAV based protocol. Note that while Subversion is mostly WebDAV and DeltaV compatible, it does have non-standard extensions.
To that end I'd point you to JavaHL or SVNKit. JavaHL comes with Subversion and uses JNI to access the Subversion libraries. SVNKit is an independent Java only implementation and includes a couple different interfaces, including one that is JavaHL compatible. If the use of the native libraries by JavaHL doesn't present a problem for you I'd recommend this since you'll have the benefit of using the same libraries as nearly every Subversion client.
If however your goal is to understand how Subversion implements the protocol on top of WebDAV and DeltaV then perhaps you want to just use a generic WebDAV and DeltaV client library to help. I'd recommend that you refer to these documents that describe how WebDAV and DeltaV are implemented within Subversion.
One thing you might want to understand is that as of Subversion 1.7 we support what we refer to as HTTPv2. HTTPv2 varies somewhat from the DeltaV standard in particular. Instead of using MKACTIVITY to start a transaction on the server we use a POST. Which has a body with a syntax something like this:
(create-txn)
or
( create-txn-with-props (PROPNAME PROPVAL [PROPNAME PROPVAL ...])
The older style which you must use with MKACTIVITY (and can use with the POST if you use create-txn instead of create-txn-with-props) is to use a PROPPATCH on the transaction or the working baseline URL.
The working baseline URL is used with MKACTIVITY and the transaction URL is used with the POST.
When using MKACTIVITY you have to use a PROPFIND on the root URL to get the version-controlled-configuration. Then do a CHECKOUT against the URL you received in response to that PROPFIND providing the activity-set href as the URL you used with MKACTIVITY. You'll get the working baseline URL back as the Location header from the CHECKOUT request. Which you can then use to issue a PROPPATCH to apply the revision properties.
When using POST, you get the transaction stub from the headers in the OPTIONS request response, the transaction name from the SVN-Txn-Name header in the response to the POST, and execute a PROPPATCH against the $transaction_stub/$transaction_name URL.
Probably the best ways to figure all this out is to setup a Subversion server and do some commits while running Subversion through a debugging proxy server such as Charles. You can force the traffic through the proxy on the svn command line with these options --config-option servers:global:http-proxy-port=8888 --config-option servers:global:http-proxy-host=127.0.0.1. If you want to see the old protocol you can include SVNAdvertiseV2Protocol off in your http configuration.
In order to support the broadest range of Subversion servers you need to implement the HTTPv1 protocol, which has more round trips and is more difficult to implement. If you want to only implement HTTPv2 you'll be limited to supporting Subversion servers newer than 1.7. In order to use HTTPv2 with maximum compatibility you'll have to detect the presence from the OPTIONS response.
As you can see it gets rather complicated so it's really not worth trying to write your own client if all you want to do is implement some basic functionality.
So you are trying to do a SVN commit using WebDAV via the SVNAutoversioning on directive?
http://svnbook.red-bean.com/en/1.7/svn.webdav.autoversioning.html
AFAIK, the spec does not allow you to provide a commit message and the server will always create one for you. Perhaps you want to look at the SVNKit library if you are trying to create SVN transactions via Java.
http://svnkit.com
I have some code that is using the Restlet framework. It is writing an ERROR into my log4j log file:
2012-05-30 12:16:42,169 3278917 ERROR [STDERR] (Thread-97:) 30-May-2012 12:16:42 org.restlet.engine.http.connector.HttpClientHelper start
INFO: Starting the default HTTP client
Is there any way I can turn this logging off? I see there is a Client.getLogger(), but I can't see a way to use that to turn logging off.
You can rely on regular Java logging configuration (java.util.logging). Restlet Framework provides a simple way to adjust those properties, programmatically. Call for example:
org.restlet.engine.Engine.setLogLevel(Level.OFF);
Hi it maybe a little late but for me the following code did it:
ClientResource resource = new ClientResource();
resource.getLogger().setLevel(Level.WARNING); //<-- important
I left out the resource configuration and exectution because they are not important;-)
I have a client sending me requests without HTTP chunking (they use content-length). When my server responds, chunking is enabled, and the client can't handle this - even though they should be able to as they are using HTTP 1.1.....
I have tried to disable chunking by removing the entry below from the axis2 config file (axis2.xml) but the response is still going back chunked.
chunked
So the question is, is there somewhere else that the chunking is being enabled that is over-riding the axis2 setting? In tomcat setting perhaps?
Webserver details - tomcat 6.0.16, axis2 2.1.3
Thanks
Mike
you can disable Chunking programatically as follows:
Options options = new Options();
[...]
options.setProperty(HTTPConstants.CHUNKED, "false");
Source: http://jcesarperez.blogspot.com/2008/10/resolviendo-problemas-de.html
If you created a stub for your web service, just do this:
myStub._getServiceClient().getOptions().setProperty(HTTPConstants.CHUNKED, false);