Content Server 16.2 REST api - HTTP 500 error when adding document with a name longer than 175 char

Jean-Christophe Savard

Hello,

I'm trying to use the REST API of our Content Server 16.2 environment to create new document nodes to CS from email (.msg) files on Windows, in a .net application. Those emails often have very long filenames.

When I use the POST "api/v2/nodes/" function to create a new document node, it works okay for any filename 175 chars long or shorter. But if I try to upload a document with a filename longer than 175 chars, I get a HTTP 500 Internal Server Error. I can add that long document to Content Server manually without problem though.

I could not find any info on a filename length limitation in the doc for the REST API. Is it a know limitation, or maybe another problem on my side?

Thanks in advance.

Carrie611

Hello

Does the 175 characters include the path and the filename?

Jean-Christophe Savard

Hello!

No it's only the filename without the path. I made sure the full length path is under the Windows max length of 254 char (since I can open the file correctly and add it correctly in CS manually, so it's not a full path length problem I think).

In my .net application, I have a MultipartFormDataContent object to which I add the file name like this:

dataContentObject.Add(new StringContent(fi.Name), "name");

dataContentObject.Add(new StringContent("144"), "type");

dataContentObject.Add(new StringContent(parentid, "parent_id");

dataContentObject.Add(httpContent, "file", fi.Name);

where "fi" is a FileInfo object pointing to my Windows document and "httpContent" is a StreamContent object containing the file data itself.

I made some tests and if I send a "fi.Name" in the "name" attribute longer than 175 char it give an error. But if I replace both "fi.Name" with "fi.Name.Substring(0, 175)" to send the first 175 char of the filename only instead, it works. Any longer value than 175 and I get a HTTP 500 error.

Matthew_Pinkney

There is a file name length limit but you'd get an error back saying you exceeded it. I'm able to use a name of length 217 without issue in Postman in my test instance.

What is the error message returned? Make sure IIS isn't intercepting the error code and discarding the more informative error message for your debugging if you are using it.

Jean-Christophe Savard

Hello,

Thank you for the help. I was indeed losing the detailed error message in my exception handling, I corrected it and here is the exception message (in french since we have a french Content Server environment):

"{"error":"Erreur lors de l'ajout de la version *filename here*. Erreur lors de l'exécution d'une instruction SQL."}"

Roughly translated: Error while adding version "*filename". Error during execution of a SQL statement.

It seems it's a SQL Insert problem on the CS side. I checked and the database NAME column in the DTREECORE table is 255 char so I don't know why the SQL insert fail. Like I said the call works with a filename at 175 char but not at 176 or more. The 176th char here in my test example is not even a special char or anything, it's just a normal letter.

Greg Griffiths

You should be able to see the same error in your CONNECT log which will include the detailed Database error message that is being returned that may help you further here.

Jean-Christophe Savard

I checked the Connect logs and I see some errors :

ERROR [1462029479434] 1718027194: KConnect::ErrLog --> [10410,8],'Echec du tampon de lecture.' 

INFO   ..

INFO [1462029479997] 1718027197: ****** DAPIVerStreamRead called ...

ERROR [1462029480028] 1718027199: KConnect::ErrLog --> [10417,1],'Erreur lors de la lecture du flux de données à partir d'une version.' 

Loosely translated: "Failure in read buffer" and "Error while reading data stream from version".

Those error don't give me much info, The same file data stream works correctly if I give a Name less than 175 char, so I don't think it's a stream problem... Maybe I should open a support ticket and send the logs to OT support since it looks like more of issue in our system than an api one?

EDIT : I tried the same operation with Postman instead of .net (with the original long name), and it works ok. So maybe it's my C# implementation that cannot handle the long name somehow, I'll make some research if there is something on .net side that cannot handle the long name in the HttpClient POST request.

Jean-Christophe Savard

Ok I made some more tests: it's the filename in "file" parameter that is causing the problem. The .net MultipartFormDataContent was initialized like this in my C# code and gave an error:

multiformDataContentObject.Add(streamContent, "file", fi.Name);

Request example that correctly upload my .msg file in CS with the correct document name:

multiformDataContentObject.Add(new StringContent(fi.Name /* very long filename more than 175 char */ ), "name");

multiformDataContentObject.Add(new StringContent("144"), "type");

multiformDataContentObject.Add(new StringContent(parentid, "parent_id");

multiformDataContentObject.Add(streamContent, "file", fi.Name.Substring(0, 175) );

So it works with a shortened version name. Anyone has an idea why the version name would have a length limit? Like the doc name, it seems the database limit in the DVERSDATA table would normally be 255 char too.

Thanks in advance!

Jean-Christophe Savard

I finally managed to fix the problem. It seems since the filename was containing french accented characters, the filename was automatically Base64 encoded by the request object in .net, which gave a Version with a garbled name like "=?utf-8?B?TWFuZGF0ICA4NDAxLTE2LUtaMDMgRG9zc2llciAgODQwMS0xNi0wMjAxIENvbn..." etc. This base64 encoding was easily getting larger than the max Version name size when uploading document with long names, which was causing the SQL insert error.

I found the solution here: c# - How to disable base64-encoded filenames in HttpClient/MultipartFormDataContent - Stack Overflow. If I convert the utf8 filename to a byte array and put this array directly in the header of the MultiformDataContent, this seems to give the correct version name when the doc is created in Content Server.