WOPI corrupting files on edit

197 Views Asked by At

I have a WOPI host running in a Blazor server application with all of the .wopitest tests passing for the desired functionality (others skipped).

When I upload a word document, I am able to view the document with no issues. I am also able to edit the document, however when I try and edit the document a second time, I get an error.

The error doesn't appear to be handled and seems to originate in the Office online javascript file. Error on attempting second edit

Following the error, I am still able to open the document for viewing. It is the same behaviour if I use the 'Editing' button in the Office Online page or directly navigate to the editing page using an edit action url.

Supplementary information:

  • Using ngrok to debug locally
  • .NET 6
  • Using SQLite database for holding file information (including path to file)
  • Using local folders for storing file contents (e.g. 'data' folder containing all files)
  • Similar issues with .xslx files beign corrupted upon editing and requiring a 'repair' when opened with Excel. This repair removes cells containing text and indicates that it removes the theme.
  • Viewing a word document gives the following console errors View document error
  • The first editing of a word document gives the following console errors Edit document error

I was expecting to be able to repeatedly edit the document.

I tried opening the file in the Desktop version of Word and got the following error Desktop Word recover

Following a recover, the document appears to work as expected in Word (desktop) but still won't open for editing through WOPI.

1

There are 1 best solutions below

0
On BEST ANSWER

Turns out it was the way the POST http request body was being saved. Still not certain what was going wrong but somewhere along the way of writing the stream into a buffer and then saving that to a file corrupted the file.

I suspect the file stream was either truncating or adding a few bytes. The interesting part being that Office Online was still able to view the file.

This indicates there is some tolerance for malformed files still being served.