gSOAP Toolkit Activity
Development toolkit for Web Services and XML data bindings for C & C++
Brought to you by:
engelen
Activity for gSOAP Toolkit
-
gSOAP Toolkit released /gsoap_2.8.133.zip
-
Robert van Engelen committed [r222] on Code
gSOAP 2.8.133 stable
-
-
gSOAP 2.8.132 stable
-
Anil Gowda M posted a comment on ticket #1318
Here is logs
-
ws4d-gsoap compilation.
-
Build fails for wsdl2h in MSYS2 with SSL enabled
-
Fixed in the upcoming 2.8.132 release.
-
#ifndef WITH_COMPAT missing for soap_dom_attribute
-
Add a feature to set preferred hashing algorithm for http da plugin
-
MD5 is not recommended as the httpda plugin documentation states. The registration of the pluging is done with your choice of hashing algorithm e.g. http_da_sha256() as the registration parameter. If no parameter is provided, then SHA256 is used by default. Therefore, the statement that MD5 is not recommended and therefore there should be an option (or priority) does not match with the reality that the API and plugin implementation that has been available for many years.
-
base64 decode is not proper for some of the input values
-
This works perfectly fine, see below. Perhaps the problem is located elsewhere in the XML or in the application itself? Examples to test the two base64 decoders. This one converts base64 strings to data: #include "stdsoap2.h" int main() { char buf[256]; int num; struct soap *ctx = soap_new(); if (soap_base642s(ctx, "MTgwNzIxMDM3MQ==", buf, sizeof(buf), &num) != NULL) printf("%s (%d)\n", buf, num); else soap_print_fault(ctx, stderr); } and this one parses base64 from standard input: int main() { char...
-
Fix incompatible integer to pointer conversion on non glibc systems
-
The suggested change will not compile on other systems, such as MacOS.
-
Build fails for wsdl2h in MSYS2 with SSL enabled
-
Thank you for your feedback. The changes will be included in the upcoming release cycle.
-
#ifndef WITH_COMPAT missing for soap_dom_attribute
-
You're right. Thank you for your feedback. The upcoming release update will be fixed.
-
Naveen Karur created ticket #1317
base64 decode is not proper for some of the input values
-
tudscr created ticket #1316
#ifndef WITH_COMPAT missing for soap_dom_attribute
-
Allow to override build date
-
Thank you for contributing to the gsoap project. Will update the project soon.
-
Bernhard M. Wiedemann created ticket #185
Allow to override build date
-
-
-
gSOAP 2.8.131 stable
-
Martin created ticket #1315
Build fails for wsdl2h in MSYS2 with SSL enabled
-
listout posted a comment on ticket #1314
Please refer https://bugs.gentoo.org/897870 for more information and a complete build log.
-
Fix incompatible integer to pointer conversion on non glibc systems
-
Alim Abaev created ticket #1313
Add a feature to set preferred hashing algorithm for http da plugin
-
Jonatan Midtgaard created ticket #1312
Default attributes in XML schema not captured by WSDL2H
-
-
gSOAP 2.8.130 stable
-
macro SOAP_SNPRINTF from stdsoap2.h may be mangled
-
No issues whatsover. Note that all uses have parenthesis in the code base: Like this: (SOAP_SNPRINTF(tmp, sizeof(tmp), 20), "&#x%lX;", c); So perfectly fine. This is to allow the result to be ignored with (void).
-
schnuette created ticket #1311
macro SOAP_SNPRINTF from stdsoap2.h may be mangled
-
-
gSOAP 2.8.129 stable
-
-
gSOAP 2.8.128 stable
-
gSOAP 2.8.128 stable
-
-
gSOAP 2.8.127 stable
-
Undefine reference to soap_traverse_xsd__dateTime
-
Adding traverse functions for custom types is meant to be done by the user, because soapcpp2 cannot "see" the internals of the custom serializable type definition. For example, if it is a struct with members like struct timeval, then the members are not visible to soapcpp2. It can only treat custom serializable types as if they are "primitive" types with no structure. If so, it's easy for soapcpp2 to generate traversal functions for these. Otherwise the user has to provide traversal functions, which...
-
Denis Porfiryev posted a comment on ticket #1302
It did close the socket when I reported the bug, not sure how the code was changed since than. I got that from a project I worked at. Adding return looks very close to removing that strange-looking line as in that case the line will not get control and the only difference is what soap_envelope_begin_in does after if blocks. If that's enough please add the change to the project's source code.
-
Not sure where you get that information from. The engine does not silently close the socket. When an error occurs, the server logic responds with an Fault message and then closes the socket, See the code in soap_begin_serve() that is responsible for this. The logic can be improved with a minor change to capture SOAP mismatch errors only when the element tag is qualified: if (!soap_element_begin_in(soap, ":Envelope", 0, NULL)) return soap->error = SOAP_VERSIONMISMATCH;
-
Silent closing of socket without sending error response is a bug!
-
Curl Example does not show how to handle digest suth.
-
CORS Private-Network headers
-
A 200 or 204 response is fine, should not be a problem either way. See also https://stackoverflow.com/questions/14702962/can-an-http-options-request-return-a-204-or-should-it-always-return-200
-
Wrong/confusing sample: Custom serializer for struct timeval
-
strerror_r issue with emscripten
-
If you run ./configure and then compile all source code with -DHAVE_CONFIG_H with config.h i n the current directory, then there won't be any issues. If there is, let us know.
-
Wrong envelope handling
-
This logic is required for SOAP 1.1/1.2 standard compliance. A version mismatch must be reported if the SOAP namespace does not match. In that case it is not a validation constraint error.
-
[GSOAP Build Failed] Please consider updating autotool scripts.
-
soap context is not being initialized for the code generated by gsoap engine when -p option is used.
-
Upcoming gsoap 2.8.127 has the code updated.
-
Namespace prefix attached in xsi:type value even for SOAP_XML_DEFAULTNS
-
Upcoming gsoap 2.8.127 has the code update suggested above.
-
Wrong implementation of WS-Discovery on checking the request type
-
Please read the gsoap WS-Discover documentation. It states that you must use soapcpp2 with option -a to match actions instead of tags.
-
Namespace prefix attached in xsi:type value even for SOAP_XML_DEFAULTNS
-
Let me explain why the old code fails. Consider: <xx:name xsi:type="xsd:string"> without prefixes this should be: <name xmlns="some-uri" xsi:type="xsd:string"> It is not correct to remove the prefix from the xsi:type, but only when the prefix matches the current default namespace of course. Now, normally we don't see any xsi:type attributes like this any longer. A better solution might be to make the following change to soap_element(): if ((soap->mode & SOAP_XML_DEFAULTNS)) { size_t n = 0; s = strchr(tag,...
-
The old code was changed/removed after 2.8.17 because it triggered a bug with the SOAP_XML_DEFAULT flag. The code is insufficient. Note that xsi:type is only useful for cases that require inheritance, i.e. to distinguish the base from a derived type. Newer gsoap versiosn do not use xsi:type by default any longer, only to disambiguate base/derived types.
-
soap context is not being initialized for the code generated by gsoap engine when -p option is used.
-
Indeed. This was on the TODO list for too long. The 2.8.127 release will include the suggested code. This was tricky, because the soap_dom_element type is not visible to the analyzer so we need to make an exception and also deeper inheritance levels should be covered recursively.
-
Issue with self-closing tag when upgrading from older gsoap version
-
The problem is not clear. What options are used? What are the build steps? What is the part of the .h interface header file for soapcpp2 that contains the custom type?
-
The problem is not clear. What options are used? What are the build steps?
-
swire created ticket #1310
Undefine reference to soap_traverse_xsd__dateTime
-
-
gSOAP 2.8.126 stable
-
-
gSOAP 2.8.125 stable
-
gSOAP 2.8.125 stable
-
gSOAP 2.8.125 stable
-
-
gSOAP 2.8.124 stable
-
Issue with self-closing tag when upgrading from older gsoap version
-
The self closing tags are releatively new to reduce the amount of XML data sent. You can enable SOAP_XML_CANONICAL to send canonical XML without self-closing tags.
-
Access violation in soap_putcookies for domain level cookies
-
A method like this should fix it: { struct hostent *temp; #ifdef AS400 temp = gethostbyname((void*)addr); #else temp = gethostbyname((char*)addr); #endif if (!temp) { soap->errnum = h_errno; hostent = NULL; } else { *hostent = *temp; } }
-
-
gSOAP 2.8.124 stable
-
Juan Perez posted a comment on ticket #1309
Previous had wrong style, this one is correct: Using the older version, it generates a closing tag like that </tag> but using the newer version it generates a self-closing tag <tag y="423" />. It's worth mentioning that the wsdl file haven't been modified from version 65
-
Issue with self-closing tag when upgrading from older gsoap version
-
Philippe Verney created ticket #111
Conditional inclusion
-
dsww created ticket #1308
Access violation in soap_putcookies for domain level cookies
-
TinySnow created ticket #1307
[GSOAP Build Failed] Please consider updating autotool scripts.
-
-
gSOAP 2.8.123 stable
-
Suyog Jain created ticket #1306
Namespace prefix attached in xsi:type value even for SOAP_XML_DEFAULTNS
-
Xianchao Yang created ticket #1305
Wrong implementation of WS-Discovery on checking the request type
-
-
-
gSOAP 2.8.122 stable
-
1 >