I am using the gSoap library to work with Exchange Online through EWS APIs. Recently, I have noticed that during the gSoap request, the soap->fpost function truncates the bearer token value, leading to an access denied issue. This token is obtained via Azure AD OAuth authentication and exceeds 2048 characters in length.
The truncation happens specifically at 2040 characters.
To address this, I have set SOAP_BUFLEN to 32K within the stdsoap2.h file and confirmed that the size of soap->buf is 64K. Despite these adjustments, soap->fpost continues to fail.
Below, I am sharing a portion of the authentication token (some sections omitted for security) and the corresponding SOAP request:
The bearer token is clearly truncated, leading to issues in authorization. Can anyone offer insight on whether there are other size parameters I should configure, or if there’s a solution available for this?
This happens because gSoap limits HTTP header line length, not the general buffer size. SOAP_BUFLEN controls the overall buffer, but HTTP headers get constrained by SOAP_HDRLEN (defaults to ~2048 characters). Besides bumping up SOAP_HDRLEN, check SOAP_MAXHTTPHEADER if you’re on a newer gSoap version. I had success with long OAuth tokens by using a custom HTTP header handler - set soap_set_omode with SOAP_IO_CHUNK or SOAP_IO_STORE flags. You could also write a custom plugin that inserts the token after building the initial headers. This skips the length restrictions since you’re handling the Authorization header yourself. Don’t forget to clean rebuild everything after changing these constants - they’re compile-time definitions.
gSoap header truncation is a nightmare. Been through this mess with Exchange integrations.
Everyone’s talking about tweaking SOAP_HDRLEN and custom callbacks, but there’s a way cleaner solution. Don’t wrestle with gSoap at all.
I hit this same wall on a project pulling calendar data from multiple Exchange accounts. Instead of fighting gSoap’s limitations, I moved everything to an automation platform.
Built a workflow that handles OAuth with Azure AD, auto-manages token refresh, and makes EWS calls without character limits. No recompiling libraries or custom header handlers.
The workflow grabs fresh tokens, hits Exchange with SOAP requests, and transforms data however you need it. Handles token expiration automatically too.
Trigger it from your app with HTTP calls - your existing code barely changes. Just swap gSoap calls for simple REST requests to your automation endpoint.
This saved me weeks of debugging header issues and library recompiles. Check out Latenode for this kind of work: https://latenode.com
I encountered a similar issue when dealing with Microsoft Graph API tokens in gSoap. The key point here is that the problem isn’t solely related to adjusting SOAP_BUFLEN; gSoap has specific constraints for HTTP headers that cause truncation around 2040 characters. To resolve this, you should also increase the SOAP_HDRLEN in your configuration. Try setting SOAP_HDRLEN to at least 8192 or more. Remember that you’ll need to recompile the gSoap library after making these changes, rather than just modifying the header file. Utilizing soap_set_recv_logfile and soap_set_sent_logfile can also prove beneficial, allowing you to track exactly what data is being sent and received, helping pinpoint where truncation occurs—often during the header parsing phase rather than the buffer itself.
Had this exact headache with Azure AD tokens last year. That 2040 character limit is hardcoded in gSoap’s HTTP header parsing.
I found something that worked better than just tweaking SOAP_HDRLEN. Override the HTTP send callback using soap->fposthdr and soap->fpost callbacks. You can manually build the Authorization header without hitting gSoap’s size restrictions.
Here’s what worked for me - set the Authorization header to empty first, then use your custom fposthdr callback to write the full bearer token straight to the socket. Completely bypasses the internal header buffer.
If you’d rather stick with the standard approach, make sure you’re setting SOAP_MAXHTTPHEADER along with SOAP_HDRLEN. Some gSoap versions check both.
One heads up - Azure tokens can get way longer than 2048 characters depending on group memberships and claims. You might want to refresh tokens more often or request minimal scopes to keep them shorter.