Uploaded a new version of a document using Content Server API but cannot open the file
I have managed to get the uploading of new versions of word files version to OT working using /v2/nodes/{id}/versions. When trying to open the new version we are receiving following messages:
"Word found unreadable content in <filename>. Do you want to recover the content...." and if clicking "Yes" I am getting another dialog saying "Word experienced an error trying to open the file...".
So, uploading works but something makes the file corrupt and I need help get this right.
I've tried a couple of ways on our side and the body sent is either of these two for my tries (neither correspond to how the content should look like but it may also be problem printing the data correct to the log itself):
First example:
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="file1.docx"
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
PK!ߤ�lZ [Content_Types].xml �(����n�0E�����Ub袪*�>�-R�{V��Ǽ��QU�
l"%3��3Vƃ�ښl �w%�=���^i7+���-d&�0�A�6�l4��L60#�Ò�S
---cutting---
)NN~�"word/webSettings.xmlPK-!�/��z;$word/fontTable.xmlPK-!|d�|Z&docProps/core.xmlPK-!�y��q� )docProps/app.xmlPK��+
----WebKitFormBoundary7MA4YWxkTrZu0gW--
Second example:
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="file1.docx"
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
PK!0ýýý[Content_Types].xml ý(ýýný0EýýýýýUb`QUýEýýýL<!Výýýýýýýý
*DýDýgýgýDýpýýeýý5)ý'=ýlTfýýýýkýýýýýHQZ)ý@`ýýýýpýq"Rýýýý=rýýýu`ýý[ýýs'ý/1>ýýýyf
---cutting---
ý#word/webSettings.xmlPK-!Gý`~ýýý$word/fontTable.xmlPK-!mýuýýý'docProps/core.xmlPK-!ýBtý3ýý*word/numbering.xmlPK-!ýýýGý3docProps/app.xmlPKMý7
----WebKitFormBoundary7MA4YWxkTrZu0gW--
Http header Content-Type = multipart/form-data;boundary=--WebKitFormBoundary7MA4YWxkTrZu0g
Not sure what additional information to add. Anyone can point to any reason why this may happen?
Answers
-
As I understand the file itself is a binary file since it is a zip archive. The encoding of content is for each file that has been compressed and not for the entire file, which makes sense. There can be different encodes for the files in the archive. Hence, the encoding doesn't matter on this level. /Copilot
P.S. I may test it though since my reference is not always right (but it does make sense). D.S.
0
Categories
- All Categories
- 122 Developer Announcements
- 53 Articles
- 150 General Questions
- 147 Thrust Services
- 56 OpenText Hackathon
- 37 Developer Tools
- 20.6K Analytics
- 4.2K AppWorks
- 9K Extended ECM
- 918 Cloud Fax and Notifications
- 84 Digital Asset Management
- 9.4K Documentum
- 31 eDOCS
- 184 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 7 XM Fax
- Follow Categories