gSOAP Toolkit Activity
Development toolkit for Web Services and XML data bindings for C & C++
Brought to you by:
engelen
Activity for gSOAP Toolkit
-
Mattias Ellert created ticket #187
Out-of-source build not working
-
Fix build with "make --shuffle=reverse"
-
gSOAP Toolkit released /gsoap_2.8.139.zip
-
Robert van Engelen committed [r228] on Code
gSOAP 2.8.139 stable
-
-
gSOAP 2.8.138 stable
-
-
gSOAP 2.8.137 stable
-
Do not overwrite CPPFLAGS when compiling samples
-
Thank you for contributing. The next release will include the changes.
-
Thank you for contributing.
-
-
gsoap 2.8.136 stable
-
steph96 posted a comment on ticket #185
The generated soapC.cpp has also a timestamp in it. It is in the source code and thus leads to trouble with ccache in our environment. See https://sourceforge.net/p/gsoap2/code/HEAD/tree/gsoap/samples/calc_xcode/soapC.cpp#l21 for example where SOAP_SOURCE_STAMP("@(#) soapC.cpp ver 2.8.135 2024-07-01 20:02:42 GMT") is written to the cpp file. Please also replace the timestamp there. The provided path is only for the wsdl2h executable not for soapcpp2. Please add support to soapcpp2 also. Thanks.
-
Do not overwrite CPPFLAGS when compiling samples
-
-
gsoap 2.8.135 stable
-
Issue with using http_extra_header with certain plugins
-
The databinding test case report Segmentation fault is executed in Ubuntu22.04
-
Thanks for reporting. The address.cpp demo example application has a missing allocation for the DOB field. The code that takes the DOB in address.cpp:166 should be: // change soap_s2dateTime to soap_xsd__dateTime when overriding the default xsd:dateTime to time_t mapping if (*(s = user_input("DOB"))) { a->dob = soap_new_dateTime(soap); if (soap_s2dateTime(soap, s, a->dob) != SOAP_OK) std::cerr << "Not a valid ISO 8601 date time (ignored)" << std::endl; } Otherwise, a->dob is null and that leads to...
-
James Wang created ticket #1320
The databinding test case report Segmentation fault is executed in Ubuntu22.04
-
Issue with using http_extra_header with certain plugins
-
This modification should work, I've tested with various examples including incorrect ones (which won't show up as a header): if (soap->http_extra_header) { const char *header = soap->http_extra_header; soap->http_extra_header = NULL; /* use http_extra_header once (assign new value before each call) */ while (*header) { const char *s = strchr(header, ':'); const char *t = strchr(header, '\n'); if (t == NULL) t = header + strlen(header); if (s != NULL && s < t && t < header + sizeof(soap->tmpbuf))...
-
Alim Abaev posted a comment on ticket #1313
@engelen, thank you!
-
Issue with using http_extra_header with certain plugins
-
Thanks for the feedback. The problem is that the extra header is allowed to contain more than one header string i.e. with \r\n separators. This won't work woth the fposthdr callback. That's why it differs. And yes, it is a bit ugly. Your suggestion to use a loop over the strings could work to use fposthder.
-
Thanks for the feedback. The problem is that the extra header is allowed to contain more than one header string i.e. with \r\n separators. This won't work woth the fposthdr callback. That's why it differs.
-
Adam Winslow created ticket #1319
Issue with using http_extra_header with certain plugins
-
Add a feature to set preferred hashing algorithm for http da plugin
-
-
gSOAP 2.8.134 stable
-
When 2.8.134 is available soon, you can upgrade but also just copy the httpda plugin source code of the new 2.8.134 release to use with your older gsoap release, if desired.
-
If the server responds with several WWW-Authenticate headers then the client side will pick the very first one that is listes as a WWW-Authenticate header. If that's MD5 then it pick that. I will update the httpda plugin in the upcoming 2.8.134 release available very soon to pick SHA-256 if the choice is MD5 or SHA-256, regardless of the order of the WWW-Authenticate headers. Basically, the client picks SHA-256 over MD5.
-
I want my client to use by default SHA256 but it uses obsolete MD5
-
Hi @engelen, Is it correct that http_da_sha256 is for server side? I have not found such option for a client side. And when a server returns two algorthms options, gSoap uses MD5 (it comes first in response headers).
-
-
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
-
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.
1 >
