Activity for Robert van Engelen
-
Robert van Engelen committed [r224] on Code
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...
-
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))...
-
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.
-
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.
-
gSOAP 2.8.133 stable
-
Home
-
gSOAP 2.8.132 stable
-
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.
-
Home
-
Allow to override build date
-
Thank you for contributing to the gsoap project. Will update the project soon.
-
gSOAP 2.8.131 stable
-
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).
-
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...
-
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;
-
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?
-
gSOAP 2.8.126 stable
-
gSOAP 2.8.125 stable
-
gSOAP 2.8.125 stable
-
gSOAP 2.8.125 stable
-
Home
-
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
-
gSOAP 2.8.123 stable
-
gSOAP 2.8.122 stable
-
gSOAP 2.8.121 stable
-
gSOAP 2.8.120 stable
-
gSOAP 2.8.119 stable
-
gSOAP 2.8.118 stable
-
gSOAP 2.8.118 stable
-
How are things going? Contact me (preferably via Genivia tech support) with follow-up questions so I can help on our side.
-
Cannot create soap 1.2 compatible requests.
-
I assume you have read the online gSOAP tutorials and manual by now, which have all the answers on how to use digest authentication: use the httpda plugin for HTTP digest authentication.
-
XSD Element extension gives warning in wsdl2h and error in soapcpp2
-
v2.8.117 is released.
-
gSOAP 2.8.117 stable
-
Thanks for the details. Will look into this to offer some feedback later, when I have time in a few days. In the meantime, note that SOAP_IO_STORE stores the message before sending it (e.g. to compute the HTTP content length) instead of serializing twice. From the top of my head I don't recall if that is possible within the curlapi.
-
You're right. Basic auth will work, but digest auth also needs to hash the message for integrity. Not quite sure how to approach this in code outside of the plugin as there needs to be some "interaction".
-
libcurl supports authentication. You won't need the http_da plugin for this. The gSOAP documentation shows how to use curl_easy_setopt with the gSOAP curlapi. To use curl_easy_setopt for authentcation, see online e.g. https://stackoverflow.com/questions/16800640/how-to-post-http-request-using-digest-authentication-with-libcurl
-
Not required with SOAP 1.2 does not imply forbidden. Note that WS-Addressing requires SOAP action headers to reroute HTTP content to other endpoints.
-
XSD Element extension gives warning in wsdl2h and error in soapcpp2
-
The fix for this issue will be included in the upcoming 2.8.117 update.
-
Sorry for the delay. Others have used gsoap with the IATA NDC schemas without problems, but perhaps that was a different set of schemas. Strange to see this issue with schema simpleType extensions, which produce the correct __itemmembers as expected but the namespace cannot be identified (it's an empty namespace), so ns1__ is missing here. I will take a look.
1 >