axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moriarty, Greg" <Greg.Moria...@inin.com>
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
wondering:

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
axis2_options_set_property().

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: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


Mime
View raw message