RE: Invalid byte 2 of 2-byte UTF-8 sequence?
Thanks for pointing that out, I should have been able to find that one myself. Most reasonable thing for me to do seems to apply the proposed workaround from AXISCPP-964, i.e. In SoapSerializer.cpp, turn serialize( ?xml version='1.0' encoding='utf-8' ?, NULL); into serialize( ?xml version='1.0' encoding='ISO-8859-1' ?, NULL); I'm no expert on character-encoding, but since AxisChar is defined in Gdefine.hpp as a normal char anyway, isn't this simply the best way to fix the issue completely? Kind regards, Iwan -Original Message- From: Nadir Amra [mailto:[EMAIL PROTECTED] Sent: donderdag 29 maart 2007 0:52 To: Apache AXIS C User List Cc: Apache AXIS C User List Subject: Re: Invalid byte 2 of 2-byte UTF-8 sequence? Iwan, This is an existing problem. See AXISCPP-964. If anyone want to provide a patch, I can include the patch. If you have a solution to fix your particular problem, then please provide the patch. Nadir K. Amra Iwan Tomlow [EMAIL PROTECTED] wrote on 03/28/2007 06:22:00 AM: Hi, when connecting an Axis-C client (v1.5) to an Axis-java webservice, the return message has the following error: soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringjava.io.UTFDataFormatException: Invalid byte 2 of 2- byte UTF-8 sequence./faultstring The only difference with all other working requests, seems the company name containing GÜTER. When debugging, the U-umlaut is showing correctly everywhere, but apparently the receiving webservice isn't getting it correctly. The source message generated by Axis-C++ looks like this in TCPMonitor: Content-Type: text/xml; charset=UTF-8 ?xml version='1.0' encoding='utf-8' ? ... ns1:companyROTTMANN HEINRICH G TER/ns1:company So it seems the character is indeed being encoded incorrectly by Axis-C? Does anyone have any hints to get this working? By the way, I receive this company-name via another webservice, and I notice that they sent me this: employerNameROTTMANN HEINRICH G#xDC;TER/employerName Maybe there is a way to configure Axis-C to do the same, sending a character reference to avoid the encoding-mismatch? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Invalid byte 2 of 2-byte UTF-8 sequence?
Hi, when connecting an Axis-C client (v1.5) to an Axis-java webservice, the return message has the following error: soapenv:Fault faultcodesoapenv:Server.userException/faultcode faultstringjava.io.UTFDataFormatException: Invalid byte 2 of 2-byte UTF-8 sequence./faultstring The only difference with all other working requests, seems the company name containing GÜTER. When debugging, the U-umlaut is showing correctly everywhere, but apparently the receiving webservice isn't getting it correctly. The source message generated by Axis-C++ looks like this in TCPMonitor: Content-Type: text/xml; charset=UTF-8 ?xml version='1.0' encoding='utf-8' ? ... ns1:companyROTTMANN HEINRICH G TER/ns1:company So it seems the character is indeed being encoded incorrectly by Axis-C? Does anyone have any hints to get this working? By the way, I receive this company-name via another webservice, and I notice that they sent me this: employerNameROTTMANN HEINRICH G#xDC;TER/employerName Maybe there is a way to configure Axis-C to do the same, sending a character reference to avoid the encoding-mismatch? Kind regards, Iwan Tomlow - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Crash in XercesHandler.cpp with in response
Sure, this is the on-the-wire message (in which I had to replace some personal data for confidentiality). The amp; in employerName causes XercesHandler to parse the data in 2 steps, and the 2nd call to XercesHandler::characters is causing problems in the use of 'cp_PreviousNameOrValue'. Thanks for your assistance, Iwan ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body getCardResponse xmlns=http://thenamespace; getCardReturn cardNumber12345/cardNumber cardState104/cardState cardValidTo03/11/2008/cardValidTo cardVersion0/cardVersion customerCode0/customerCode dateOfBirth01/01/1975/dateOfBirth employerCitySOMEWHERE/employerCity employerCountryXX/employerCountryemployerNameBOOT amp; BUTEIJN/employerName employerNumber1234/employerNumberemployerPhone/999.999.999/em ployerPhone employerStreetTHERE/employerStreet employerZipAA/employerZip firstNameFIRST/firstName groupNumber1/groupNumber homeAddressCityCITY/homeAddressCity homeAddressCountryXX/homeAddressCountry homeAddressStreetSTREET 11/homeAddressStreet homeAddressZipAA/homeAddressZip homePhone xsi:nil=true/ lastNameLAST/lastName nationalityXX/nationality personnelNumber/personnelNumber qualification1 xsi:nil=true/qualification2 xsi:nil=true/qualification3 xsi:nil=true/subgroupNumber xsi:nil=true/ /getCardReturn /getCardResponse /soapenv:Body /soapenv:Envelope -Original Message- From: Adrian Dick [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 mei 2006 10:21 To: Apache AXIS C User List Subject: RE: Crash in XercesHandler.cpp with in response Hi, As we've now excluded the illegal use of '', it could be related to how the SOAP message is being received, I know of some bugs fixed in 1.6 which could cause similar problems to those you describe. Is it possible for you to attach the on-the-wire SOAP/HTTP message causing this problem? Thanks, Adrian ___ Adrian Dick ([EMAIL PROTECTED]) Iwan Tomlow [EMAIL PROTECTED] wrote on 15/05/2006 16:41:16: Hm, sorry I didn't make this clear enough: when looking at the data over the wire, the ampersand is escaped correctly. The webservice is deployed with axis-java, so no problems there. My example should read nameBOOT amp; BUTEIJN/name. The amp; was already resolved by xerces when I copy/pasted the value to this e-mail, sorry for the confusion. So Xerces parser has no problems at all, but there seems to be a bug in the XercesHandler implementation in Axis. Btw, I have the problem with both Xerces 2.2.0 (as included in axis 1.5 release), and also when I build Axis 1.5 myself linked with Xerces 2.7.0. I have not been able to use the 1.6 nightly build yet, and I would rather be able to quickly fix the production problem with a 1.5 patch first. Regards, Iwan -Original Message- From: Adrian Dick [mailto:[EMAIL PROTECTED] Sent: maandag 15 mei 2006 17:20 To: Apache AXIS C User List Subject: Re: Crash in XercesHandler.cpp with in response Hi, Under the SOAP (and underlying XML) standards the ampersand character is reserved, so you are not permitted to use it within data. You will need to ensure any occurances are correctly encoded --- ie: '' becomes amp;. It looks quite likely the Xerces Parser is failing when it hits this invalid use of ''. How is this XML data being produced? Are you using xsd:any -- in which case you'll need to ensure this encoding takes place -- or are you seeing an error in the Axis serialization code, where this should be taking place on your behalf. Are you in a position to test if this problem is still present with the latest Axis 1.6 nightly builds? Regards, Adrian ___ Adrian Dick ([EMAIL PROTECTED]) Iwan Tomlow [EMAIL PROTECTED] wrote on 15/05/2006 13:34:04: Hi all, I'm using the Axis C++ 1.5 in a production project, and we are experiencing problems when the response from the webservice contains ampersands in the xml-data, like nameBOOT BUTEIJN/name. The generated Axis-client stub crashes (with 'Invalid Address specified to RtlFreeHeap' in MCVC6.0 debugger) on the following code in XercesHandler::characters free(const_cast char* (cp_PreviousNameOrValue)); free(cp_CurrentNameOrValue); I found a jira-issue (AXISCPP-825) that seems to address this issue, but the reported fix (change free to delete[]) does not work for me, the result is the same. Does anyone have this issue, any hints? Strange thing: it appears everything works fine if a point my XMLParser in axiscpp.conf to the debug-library 'AxisXMLParser_D.dll' instead of the release-build, but I'm afraid that is just a coincidence. Any help appreciated. Kind regards, Iwan Tomlow
RE: Crash in XercesHandler.cpp with in response
Ah, that's more difficult, since the webservice is only made available over HTTPS, so I can't just drop tcpmon in between. The xml-data is actually taken from the log the server has written just before posting the reply. I really think it's more of a memory issue as described in AXISCPP-825, but that fix alone doesn't seem enough. I've been experimenting some more, and it doesn't always crash: in debug mode it works fine most of the time; on Windows XP the release mode crashes sometimes; on Windows 2000 however, the release version crashes consistently - and the production client-app must run on a Windows 2000 touchscreen terminal :( Regards, Iwan -Original Message- From: Adrian Dick [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 mei 2006 14:55 To: Apache AXIS C User List Subject: RE: Crash in XercesHandler.cpp with in response Hi, Ok, I can't see anything obviously wrong with your SOAP message ... I wouldn't expect the amp; to cause problems, as we have a passing testcase to check the correct encoding/decoding of this, and looking through the SVN history the code which handles encoding/decoding hasn't been touched since before the release of 1.5. I'm wondering if perhaps you're hitting a problem with the transport/parser interaction. I should have asked before, can you also include the HTTP headers, etc. so I can check if there are any content/chunk length issues here. Regards, Adrian ___ Adrian Dick ([EMAIL PROTECTED]) Iwan Tomlow [EMAIL PROTECTED] wrote on 16/05/2006 10:01:03: Sure, this is the on-the-wire message (in which I had to replace some personal data for confidentiality). The amp; in employerName causes XercesHandler to parse the data in 2 steps, and the 2nd call to XercesHandler::characters is causing problems in the use of 'cp_PreviousNameOrValue'. Thanks for your assistance, Iwan ?xml version=1.0 encoding=UTF-8? soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; soapenv:Body getCardResponse xmlns=http://thenamespace; getCardReturn cardNumber12345/cardNumber cardState104/cardState cardValidTo03/11/2008/cardValidTo cardVersion0/cardVersion customerCode0/customerCode dateOfBirth01/01/1975/dateOfBirth employerCitySOMEWHERE/employerCity employerCountryXX/employerCountryemployerNameBOOT amp; BUTEIJN/employerName employerNumber1234/employerNumberemployerPhone/999.999.999/ em ployerPhone employerStreetTHERE/employerStreet employerZipAA/employerZip firstNameFIRST/firstName groupNumber1/groupNumber homeAddressCityCITY/homeAddressCity homeAddressCountryXX/homeAddressCountry homeAddressStreetSTREET 11/homeAddressStreet homeAddressZipAA/homeAddressZip homePhone xsi:nil=true/ lastNameLAST/lastName nationalityXX/nationality personnelNumber/personnelNumber qualification1 xsi:nil=true/qualification2 xsi:nil=true/qualification3 xsi:nil=true/subgroupNumber xsi:nil=true/ /getCardReturn /getCardResponse /soapenv:Body /soapenv:Envelope -Original Message- From: Adrian Dick [mailto:[EMAIL PROTECTED] Sent: dinsdag 16 mei 2006 10:21 To: Apache AXIS C User List Subject: RE: Crash in XercesHandler.cpp with in response Hi, As we've now excluded the illegal use of '', it could be related to how the SOAP message is being received, I know of some bugs fixed in 1.6 which could cause similar problems to those you describe. Is it possible for you to attach the on-the-wire SOAP/HTTP message causing this problem? Thanks, Adrian ___ Adrian Dick ([EMAIL PROTECTED]) Iwan Tomlow [EMAIL PROTECTED] wrote on 15/05/2006 16:41:16: Hm, sorry I didn't make this clear enough: when looking at the data over the wire, the ampersand is escaped correctly. The webservice is deployed with axis-java, so no problems there. My example should read nameBOOT amp; BUTEIJN/name. The amp; was already resolved by xerces when I copy/pasted the value to this e-mail, sorry for the confusion. So Xerces parser has no problems at all, but there seems to be a bug in the XercesHandler implementation in Axis. Btw, I have the problem with both Xerces 2.2.0 (as included in axis 1.5 release), and also when I build Axis 1.5 myself linked with Xerces 2.7.0. I have not been able to use the 1.6 nightly build yet, and I would rather be able to quickly fix the production problem with a 1.5 patch first. Regards, Iwan -Original Message- From: Adrian Dick [mailto:[EMAIL PROTECTED] Sent: maandag 15 mei 2006 17:20 To: Apache AXIS C User List Subject: Re: Crash in XercesHandler.cpp with in response Hi, Under the SOAP (and underlying XML) standards the ampersand character is reserved, so you are not permitted to use it within data. You will need to ensure any occurances are correctly encoded
RE: Crash in XercesHandler.cpp with in response
Hi all,
Just letting you know I think the problem is solved!
I was trying to get the 1.6 nightly build to work, but kept running into
other problems.
However, I took a glance at the XercesHandler.cpp included in the 1.6,
and it seems the part that was causing me problems has been changed
significantly (more then described in AXISCPP-825).
I applied this change to my 1.5 sources, rebuild AxisXmlParser.xml, and
don't get the crash anymore on any machine!
Just for reference, the code for the 'PreviousNameOrValue' case in
XercesHandler::characters was changed to:
// The following code is necessary as it is important to get the correct
heap
// (i.e the one that XMLString is using!) when creating a memory object
to put
// back into 'm_pNextElement-m_pchNameOrValue'. By using the XMLString
// function, we can ensure that only the memory belonging to (and thus
able to
// destroy) the same segment as XMLString is used. If you don't
understand
// what is going on, don't change it!
if (cp_PreviousNameOrValue)
{
// Get a pointer to the transcoded character.
char * pTransChar = XMLString::transcode( chars);
// Create a dummy string and populate.
char * psDummy = new char[ strlen(
m_pNextElement-m_pchNameOrValue) +
strlen( pTransChar) + 1];
strcpy( psDummy, m_pNextElement-m_pchNameOrValue);
strcat( psDummy, pTransChar);
// Create pointer to new Name or Value string.
char * pNewNameOrValue = XMLString::replicate(
psDummy);
// Delete the old Name and Value string.
XMLString::release( const_castchar**
((m_pCurrElement-m_pchNameOrValue)));
// Assign the new value of Name or Value string.
m_pNextElement-m_pchNameOrValue = pNewNameOrValue;
// Clean up.
delete [] psDummy;
XMLString::release( pTransChar);
}
Regards,
Iwan
-Original Message-
From: Iwan Tomlow [mailto:[EMAIL PROTECTED]
Sent: dinsdag 16 mei 2006 15:13
To: Apache AXIS C User List
Subject: RE: Crash in XercesHandler.cpp with in response
Ah, that's more difficult, since the webservice is only made available
over HTTPS, so I can't just drop tcpmon in between.
The xml-data is actually taken from the log the server has written just
before posting the reply.
I really think it's more of a memory issue as described in AXISCPP-825,
but that fix alone doesn't seem enough.
I've been experimenting some more, and it doesn't always crash: in debug
mode it works fine most of the time; on Windows XP the release mode
crashes sometimes; on Windows 2000 however, the release version crashes
consistently - and the production client-app must run on a Windows 2000
touchscreen terminal :(
Regards,
Iwan
-Original Message-
From: Adrian Dick [mailto:[EMAIL PROTECTED]
Sent: dinsdag 16 mei 2006 14:55
To: Apache AXIS C User List
Subject: RE: Crash in XercesHandler.cpp with in response
Hi,
Ok, I can't see anything obviously wrong with your SOAP message ... I
wouldn't expect the amp; to cause problems, as we have a passing
testcase to check the correct encoding/decoding of this, and looking
through the SVN history the code which handles encoding/decoding hasn't
been touched since before the release of 1.5.
I'm wondering if perhaps you're hitting a problem with the
transport/parser interaction.
I should have asked before, can you also include the HTTP headers, etc.
so I can check if there are any content/chunk length issues here.
Regards,
Adrian
___
Adrian Dick ([EMAIL PROTECTED])
Iwan Tomlow [EMAIL PROTECTED] wrote on 16/05/2006 10:01:03:
Sure, this is the on-the-wire message (in which I had to replace some
personal data for confidentiality).
The amp; in employerName causes XercesHandler to parse the data in
2 steps, and the 2nd call to XercesHandler::characters is causing
problems in the use of 'cp_PreviousNameOrValue'.
Thanks for your assistance,
Iwan
?xml version=1.0 encoding=UTF-8? soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
soapenv:Body
getCardResponse xmlns=http://thenamespace; getCardReturn
cardNumber12345/cardNumber cardState104/cardState
cardValidTo03/11/2008/cardValidTo
cardVersion0/cardVersion
customerCode0/customerCode
dateOfBirth01/01/1975/dateOfBirth
employerCitySOMEWHERE/employerCity
employerCountryXX/employerCountryemployerNameBOOT amp;
BUTEIJN/employerName
employerNumber1234/employerNumberemployerPhone/999.999.999/
em
ployerPhone
employerStreetTHERE/employerStreet
employerZipAA/employerZip
firstNameFIRST/firstName
groupNumber1/groupNumber
homeAddressCityCITY/homeAddressCity
homeAddressCountryXX/homeAddressCountry
homeAddressStreetSTREET 11/homeAddressStreet
RE: [AXIS][AXIS C++] HTTPS support Authentication
Hi, a few months ago, I was asked to change my Axis C++ (1.5) client to work with SSL as soon as possible, and I did manage to get it working (to a axis-java webservice). Took me a little time to dig into this and also some small changes to the 1.5 sources (which are probably unnecessary if you can use the SVN-head). There are some tricky bits, the most important: * you must build the HTTPSSLChannel.dll yourself * most axiscpp.conf properties have defaults, so you don't need special settings for a normal client, but for SSL you must use AXISCPP_DEPLOY environment variable and appropriate axiscpp.conf (with Channel_HTTP_SSL: .../HTTPSSLChannel.dll) Check out this thread and replies in the archives for my findings: http://mail-archives.apache.org/mod_mbox/ws-axis-c-user/200602.mbox/%3c6 [EMAIL PROTECTED] I'm also using basic authentication, this is done easily using (where 'sAuth' is the base64-encoded string for 'user:pwd') snip MyWebServiceSoap s(sEndPoint, APTHTTP1_1); if (bUseProxy) s.setProxy(sProxySrv, nProxyPrt); s.setTransportTimeout(AXIS_TRANSPORT_TIMEOUT); s.setTransportProperty(Authorization, Basic + sAuth); /snip Kind regards, Iwan Tomlow From: Ephemeris Lappis [mailto:[EMAIL PROTECTED] Sent: dinsdag 25 april 2006 17:08 To: axis-c-user@ws.apache.org Subject: [AXIS][AXIS C++] HTTPS support Authentication Hello. Could somebody confirm a HTTPS support with AXIS C++, in the client side context ? Is some complementary library needed for such a SSL support ? In the same context, does AXIS support HTTP Basic authentication using client side stub's properties, the same way the Java version does ? Thanks. -- Ephemeris Lappis
RE: SSL Client
Title: Message
Hi,
thanks
for the reply, I did actually get it working with the changes I described -
these were applied to the Axis C++ 1.5 Final sources.
I was
actually looking for the repository on the Apache website, and the main page at
http://ws.apache.org/axisstill
links to 'Get Involved' 'CVS Repository' = http://ws.apache.org/axis/cvs.html-
but the links there are no longer valid?
One
extra remark for others trying to get SSL to work: I noticed that even for a
client-only installation, I needed the AXISCPP_DEPLOY environment variable and
an appropriate axiscpp.conf configuration file there for SSL to work (with
Channel_HTTP_SSL: ...\HTTPSSLChannel.dll in it).
This
axiscpp.conf was not necessary for the client without SSL, is that
correct?
Kind
regards,
Iwan
-Original Message-From: Fred Preston
[mailto:[EMAIL PROTECTED] Sent: dinsdag 21 februari 2006
17:37To: Apache AXIS C User ListSubject: RE: SSL
ClientHi Iwan,
Did you get SSL
working? Also, you should not be downloading the Axis code from CVS
repository as this abandoned months ago and the new Axis repository is now in
SVN (it should all be on the Apache web site :-) ). From your code
snippets, it looks like you are using quite an old version of the code and it
could be that some of your problems have already been resolved when you try
the latest code extracted from SVN repository :-) Regards,Fred Preston.
Iwan Tomlow
[EMAIL PROTECTED]
21/02/2006 07:57 Please respond to "Apache AXIS C User
List"
To:
"'Apache AXIS C User List'"
axis-c-user@ws.apache.org cc:
"'axis-c-dev@ws.apache.org'"
axis-c-dev@ws.apache.org Subject:
RE: SSL Client
One
thing I forgot to mention: to prevent the crash, I also had to changethe
following in xml\XMLParserXerces.cpp:Ln 79:const AnyElement*
XMLParserXerces::next(bool isCharData){ bool bCanParseMore
= false; if(!m_bFirstParsed)
{-
m_pParser-parseFirst(*m_pInputSource, m_ScanToken);-
m_bFirstParsed = TRUE;+
m_bFirstParsed =
m_pParser-parseFirst(*m_pInputSource,m_ScanToken);+
if (!m_bFirstParsed)+
return
NULL; }Kind regards,Iwan
Tomlow-----Original Message-From: Iwan Tomlow
[mailto:[EMAIL PROTECTED] Sent: dinsdag 21 februari 2006 8:53To:
'Apache AXIS C User List'Cc: 'axis-c-dev@ws.apache.org'Subject: RE:
SSL ClientHello,Just to let you know I managed to get the
SSL configured usingvc\transport\Axis3\HTTPSSLChannel.However, I think
I stumbled over a bug in the transport layer, because theAxis-client was
always crashing when using SSL. Can't seem to access theCVS-sources at the
moment, so I don't know if it has been noticed and fixedalready, so I'll
post it here.Debugging showed the Xerces-parser was using bogus data
to throw aUTF8FormatException, so the following code in
ClientAxisEngine.cpp failed:Ln 223: int
nSoapVersion = m_pDZ-getVersion (); if
(nSoapVersion == VERSION_LAST) /* version not supported
*/ {
Status = AXIS_FAIL;
//
return AXIS_FAIL;The
status was indeed AXIS_FAIL, but because the return-statement iscommented
out, the subsequent call to "m_pDZ-getHeader ();" caused a crashin the
Xerces parser.I finally tracked it down to what I think is a bug in
the getBytes() inaxis3/HTTPTransport.cpp (Ln 588). Probably because of
using SSL, what I wasreceiving after the HTTP-header was always a first
chunk containing *only*the chunk size + CRLF, nothing more. This caused
the following code to neverexecute extra reads to really get any of the
chunk data:
//There might be
chunk extensions in there too but we maynot need them
unsigned
int endOfChunkData =m_strReceived.find( "\r\n");
// make sure we have read at least some part of the
message
if ( endOfChunkData == std::string::npos)
{endOfChunkData was 3 in this case (data was "4db\r\n"), and
data was neverread. I tried to fix it like this, which worked for me (not
at all sure thatthis is a complete and trustworhty fix); this should make
sure at least someof the actual chunk data is read before
continuing:
// make sure we
have read at least some part of the message-
if( endOfChunkData ==
std::string::npos)+
std::string::size_type nLen
=m_strReceived.length ();+
if ( endOfChunkData ==
std::string::npos ||+
RE: SSL Client
One thing I forgot to mention: to prevent the crash, I also had to change
the following in xml\XMLParserXerces.cpp:
Ln 79:
const AnyElement* XMLParserXerces::next(bool isCharData)
{
bool bCanParseMore = false;
if(!m_bFirstParsed)
{
- m_pParser-parseFirst(*m_pInputSource, m_ScanToken);
- m_bFirstParsed = TRUE;
+ m_bFirstParsed = m_pParser-parseFirst(*m_pInputSource,
m_ScanToken);
+ if (!m_bFirstParsed)
+ return NULL;
}
Kind regards,
Iwan Tomlow
-Original Message-
From: Iwan Tomlow [mailto:[EMAIL PROTECTED]
Sent: dinsdag 21 februari 2006 8:53
To: 'Apache AXIS C User List'
Cc: 'axis-c-dev@ws.apache.org'
Subject: RE: SSL Client
Hello,
Just to let you know I managed to get the SSL configured using
vc\transport\Axis3\HTTPSSLChannel.
However, I think I stumbled over a bug in the transport layer, because the
Axis-client was always crashing when using SSL. Can't seem to access the
CVS-sources at the moment, so I don't know if it has been noticed and fixed
already, so I'll post it here.
Debugging showed the Xerces-parser was using bogus data to throw a
UTF8FormatException, so the following code in ClientAxisEngine.cpp failed:
Ln 223:
int nSoapVersion = m_pDZ-getVersion ();
if (nSoapVersion == VERSION_LAST) /* version not supported */
{
Status = AXIS_FAIL;
// return AXIS_FAIL;
The status was indeed AXIS_FAIL, but because the return-statement is
commented out, the subsequent call to m_pDZ-getHeader (); caused a crash
in the Xerces parser.
I finally tracked it down to what I think is a bug in the getBytes() in
axis3/HTTPTransport.cpp (Ln 588). Probably because of using SSL, what I was
receiving after the HTTP-header was always a first chunk containing *only*
the chunk size + CRLF, nothing more. This caused the following code to never
execute extra reads to really get any of the chunk data:
//There might be chunk extensions in there too but we may
not need them
unsigned int endOfChunkData =
m_strReceived.find( \r\n);
// make sure we have read at least some part of the message
if ( endOfChunkData == std::string::npos)
{
endOfChunkData was 3 in this case (data was 4db\r\n), and data was never
read. I tried to fix it like this, which worked for me (not at all sure that
this is a complete and trustworhty fix); this should make sure at least some
of the actual chunk data is read before continuing:
// make sure we have read at least some part of the message
- if( endOfChunkData == std::string::npos)
+ std::string::size_type nLen =
m_strReceived.length ();
+ if ( endOfChunkData == std::string::npos ||
+ endOfChunkData + 2 = nLen )
{
iIterationCountdown = 100;
do
{
m_pszRxBuffer [0] = '\0';
*m_pActiveChannel
m_pszRxBuffer;
if( strlen( m_pszRxBuffer)
== 0)
{
iIterationCountdown--;
}
else
{
iIterationCountdown
= 100;
}
- m_strReceived =
m_pszRxBuffer;
- endOfChunkData =
m_strReceived.find( \r\n);
- } while( endOfChunkData ==
std::string::npos iIterationCountdown 0);
+ m_strReceived +=
m_pszRxBuffer;
+ nLen = m_strReceived.length
();
+ endOfChunkData =
m_strReceived.find(\r\n);
+ } while( ( endOfChunkData ==
std::string::npos || endOfChunkData + 2 = nLen )
+
iIterationCountdown 0);
}
Kind regards,
Iwan Tomlow
-Original Message-
From: Iwan Tomlow [mailto:[EMAIL PROTECTED]
Sent: vrijdag 17 februari 2006 16:31
To: 'axis-c-user@ws.apache.org'
Subject: SSL Client
Hi, I've been happily using Axis C++ 1.5 for client development, but now
urgently (and unwarned) need to be able to access the webserver over https.
I know it should be possible to link OpenSSL with Axis, but seem to be
unable
SSL Client
Hi, I've been happily using Axis C++ 1.5 for client development, but now urgently (and unwarned) need to be able to access the webserver over https. I know it should be possible to link OpenSSL with Axis, but seem to be unable to find the right documentation (the info at http://ws.apache.org/axis/cpp/winuser-guide.html#ssl is absolutely cryptic to me - where is vc\transport\Axis2\Axis2SSLChannel?) Does anyone know how to get a client working over https? What I get now = HTTPTransportException:Client attempted to use secure transport (https) without an SSL layer Strange thing is that the client works automatically when testing internally - does Axis somehow 'downgrade' to normal htpp if https can't be used? Or does this have to do something with me already having build OpenSSL on my development machine? Thanks in advance for any pointers, Iwan Tomlow
RE: Invalid C++ with ignoring anonymous type
Ok, thanks for the explanation, that makes things a little more clear. Unfortunately, I don't control the WSDL-definition, I just received it and have to create a C++-client for it. My knowledge about WSDL itself is rather limited, guess I will have to look deeper into that first... -Original Message- From: John Hawkins [mailto:[EMAIL PROTECTED] Sent: woensdag 30 november 2005 17:13 To: Apache AXIS C User List Subject: RE: Invalid C++ with ignoring anonymous type Iwan Tomlow [EMAIL PROTECTED] wrote on 30/11/2005 11:38:13: Rpc or doc: the default for WSDL2Ws, that is rpc/enc as I gather from the documentation? Rpc or doc is related to your WSDL definition - not what wsdl2ws produces. In you care you using rpc/encoded. I would recommend using doc/literal as this is ws-i compliant and rpc/encoded is not. We support doc/literal far better. You've also got refs in here - which are not supported. They might be supported in 1.6 which is due out in the next few weeks. I suggest, if you can, recreate the wsdl with doc/literal bindings and without refs. My command is java org.apache.axis.wsdl.wsdl2ws.WSDL2Ws ref_mod.wsdl -o./Out -lc++ -sclient I did see an issue in jira stating that refs didn't work, but the sample provided in axis-c-1-5\deploy\wsdls\ref.wsdl produced C++ code without problems? I attached the modified ref.wsdl again, hope it comes through this way. Thanks for your help [attachment ref_mod.wsdl deleted by John Hawkins/UK/IBM]
Invalid C++ with ignoring anonymous type
Hello, I'm having trouble with creating C++ sources for the WSDL for a project I'm starting on (using Axis C++ 1.5). The wsdl is rather complex, including lots of xsd-schemas and working with references, but I managed to reproduce the problem with some small changes to the ref.wsdl example (attached). After these change, WSDL2Ws produces the following output: ignoring anonymous type intComp ignoring anonymous type intItem Code generation completed. And in the resulting hpp-file, you see invalid stuff like: STORAGE_CLASS_INFO intItem echoInt(intComp* Value0); This looks more or less the same problem as in AXISCPP-753, but that issue only talks about complex types. Here, the problem also exists with simple types defined as element name=intItem simpleTyperestriction base=int.../restriction/simpleType /element Instead of the default in the original ref.wsdl: element name=intItem type=int / Is there any way around this problem? Kind Regards, Iwan Tomlow
