Skip to main content
I'm trying to convert a XML document with binary data to a zip-file via a self developed .NET Core 2.1 Web API using a process flow with a http connector. It's a follow up on this topic: https://community.thinkwisesoftware.com/deployment-12/moving-to-azure-sql-database-azure-file-storage-713#post2018



When testing the POST call via Postman and a simple .NET console application I receive the result as expected.



When using the process flow using a http connector, it returns an error in the SF-Debugger:

The remote server returned an error: (411) Length Required.



This could indicate the Content-Length header must be applied, so I did:



(Please note this is a fixed length, because the Content is also fixed value for now.)



Unfortunately this results in an error:



code:
The 'Content-Length' header must be modified using the appropriate property or method.
Parameter name: name
at System.Net.WebHeaderCollection.ThrowOnRestrictedHeader(String headerName)
at System.Net.WebHeaderCollection.Add(String name, String value)
at Thinkwise.Shared.ObjectModel.ProcessAction.NoContext.HttpConnector.PerformInternal(ActiveProcessFlow activeFlow, Pending pendingProcessAction, TSFController targetController)
at Thinkwise.Shared.ObjectModel.ProcessAction.Perform(ActiveProcessFlow activeFlow, Pending pendingProcessAction, TSFController sourceController)
at Thinkwise.Shared.ActiveProcessFlow.executeActiveProcessAction(IProcessActionStartParameters startParameters)




Looks like it's not allowed to add the Content-Length explicitly. Anyone any clue about what to do?



The .NET code for comparison that does work:

code:
static void Test()
{
var bodyToSend = @"TestTest.csv0xbinaryContentstrippedaway";
var data = Encoding.ASCII.GetBytes(bodyToSend);
var url = "https://server/api/xmltozip";


HttpWebRequest request = WebRequest.Create(url) as HttpWebRequest;
request.Method = "POST";


// not necessary
// request.ContentType = "application/xml";
// request.ContentLength = data.Length;
// request.Expect = "application/json";


request.GetRequestStream().Write(data, 0, data.Length);


var response = request.GetResponse() as HttpWebResponse;
var stream = response.GetResponseStream();
var destination = new FileStream(@"C:\Temp\fromapi.zip", FileMode.Create);
try
{
stream.CopyTo(destination);
destination.Close();
}
finally
{
destination.Dispose();
}
}
Hello René,



You are correct, this is definitely an issue and sadly there is no workaround for it.



Can you report this issue in TCP? That way you can track its progress and you will be informed when the issue is resolved.
Well, the weird thing is, all the steps I've done above is done in a 'Sandbox' project. This doesn't work, but when I apply the same steps in the real product project (for the real use case), it does work. I haven't yet found the differences between the two projects. I'm currently don't have the time to find out, but when so I'll keep you informed.



So the good news, I can unzip and transform a zip file to XML, the bad news is that I don't know why it works in the product-project and not in the sandbox-environment.
Hello René,



I'm not entirely sure why the http connector gives the 411 Length Required response while the console application does not, even though it doesn't set the ContentLength property. You're right that this is pretty weird.



However, it is definitely an issue that it's entirely impossible to set the Content-Length header on the http connector and I do think that fixing this issue would give you the workaround needed to resolve the problem.

Hey René,

The Content-Length header will now no longer be added to the normal headers, for it has a separate property to set the value for this. This also counts for Accept and Content-Type headers.

If you are interested you can see a list of all special headers here:
https://docs.microsoft.com/en-us/dotnet/api/system.net.webheadercollection.isrestricted?view=netframework-4.8

We now use that method to check if the given header can be set in a normal way or should be set with a separate property.

The next GUI release which will come the 3rd of March will contain this fix.

If you have any further questions please let me know.

​​​​​​​Kind Regards,
Roel


Reply