axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moriarty, Greg" <>
Subject two bug reports
Date Thu, 24 Jan 2008 05:24:02 GMT
A few months ago, I had researched using Axis2/C 1.1 as a client-side
API (specifically, to use Microsoft's Exchange 2007 web services).
However, due to a few bugs, some limitations, and unneeded complexity, I
abandoned it and switched to writing and parsing the SOAP envelopes
myself, and using libcurl for the HTTP functionality. Since I saw that
1.2 was released, I decided to take a look to see if the bugs I found
were fixed. Since libcurl serves my needs I don't really have any
motivation to try Axis2/C again, but I thought I would still report two
bugs for the community's sake.

The first bug I noticed is in http_sender.c, I was experiencing a crash
in axis2_http_sender_configure_http_basic_auth(). I haven't tested it in
Axis2/C 1.2, but it looks like the same bug is still there.

  int plen = axutil_strlen (uname) + axutil_strlen (passwd) + 1;
  sprintf (to_encode, "%s:%s", uname, passwd);

The to_encode buffer is one character short. Someone either forgot to
include room for the colon, or the terminating null. The simple fix is
to replace "+ 1" with "+ 2".

The second bug I noticed is in axis2_libcurl.c, there are three lines
that say:

  char tmp_buf[10];
  sprintf (tmp_buf, "%d", buffer_size);
  headers = curl_slist_append (headers, axutil_stracat (env,
content_len, tmp_buf));

I had to comment these out. Libcurl will determine the Content-Length
itself based on the data you pass to curl_easy_opt(handler,
CURLOPT_WRITEDATA, data). While explicitly specifying the Content-Length
is not a problem (though completely unnecessary) with no authentication
or basic authentication, it causes a problem with authentication
mechanisms that require challenge/response (such as NTLM). The
Content-Length for the challenge will specify a non-zero Content-Length,
but the HTTP body will be empty. With IIS at least, this results in a
HTTP error 400 (Bad Request). I can send a Wireshark network capture (or
screenshots) if anyone wants to see what I'm talking about.

While these are the only two bugs that I noticed might need fixing, I
suppose someone might ask what the other bugs, limitations, and
unnecessary complexities were. Here are some of them in case you are

1. The WSDL codegen (from Axis2/Java 1.3) was generating invalid C code
with Microsoft's WSDL. It was trivial to fix with a couple search and
replaces though. I was using the publicly released version (and not
nightly build), so maybe it has improved.

2. When using Axis2/C with libcurl, there is no way to specify any of
the libcurl parameters such as authentication username/password, or any
of the SSL parameters. I had to hard-code things in
axis2_libcurl_send(), such as CURLOPT_HTTPAUTH, CURLOPT_USERPWD, and
CURLOPT_CAPATH. Again, it is trivial to fix, but it would be nice if
there was some way to pass arbitrary libcurl parameters through

3. As far as unneeded complexity, it didn't seem in my case that Axis2/C
was really adding a lot of functionality. I have the impression that
Axis2/C would be much more useful if I was writing a web service
(server) than when writing a consumer of a web service (client), since
the former is typically a lot more complex. Considering that I was
having to parse the XML myself anyway in the SOAP responses (unlike SOAP
APIs like .NETs and perhaps AxisC++, where you are given nice classes
that represent XML nodes, and class member variables for the XML
attributes and text), it seemed about the only thing that Axis2/C was
adding for me was not having to formulate the SOAP requests myself and
instead just call a codegen'ed stub function. But then #1 and #4 (below)
eliminated even that advantage. Also, as far as install, Axis2/C
requires a lot of files in a directory structure, an axis2.xml file,
AXIS2_HOME environment variable, etc., whereas libcurl requires a single
file at that's it.

4. The "breaking point" for me was that the stub functions weren't
allowing me to specify certain information in the <soap:header>. For
example, Exchange Web Services uses SOAP headers to pass in an XML
element called <ExchangeImpersonation>, which provides a proxy
authorization mechanism. In other words, you authenticate through HTTP
as an admin user, but then specify the user's mailbox you wish to access
with the <ExchangeImpersonation> node in the SOAP header. The codegen'ed
stub provided a parameter for this node (and other optional nodes in the
header), but it doesn't do anything with it. Again, maybe this is
something that will improve with a more recent version of Axis2/Java.

Please don't construe any of this as criticism of Axis2/C in general. I
can certainly see great benefit it provides. I just wanted to provide
the bug reports and how it didn't suit my particular situation.

Greg Moriarty

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message