WebDAV protocol difference from 2016 to 365

[SeanL95]

Hey

Don't know if this is the right forum but hope you can help. 

I have a client who uses a custom WebDAV on-premise server together with Saperion as document handler, they do NOT use SharePoint.
They wish to upgrade from Office 2016 to Office 365, but we've run into some problemes which I suspect can have something to do with the WebDAV protocol.
I have used Fiddler to see how Word communicate with WebDAV and see no big difference other than the order of calls, and that 365 tries to make a POST call to what looks like SharePoint.

When we want to edit the document the following sequence of calls are made to the WebDAV server:

2016:
OPTIONS
HEAD (423 LOCK)
OPTIONS
LOCK (Response: Lockdiscorvery --- locktoken -- href -- opaquelocktoken)
GET
PROPFIND
HEAD

365:
OPTIONS
OPTIONS
HEAD (423 LOCK)
LOCK (Response: Lockdiscorvery --- locktoken -- href -- opaquelocktoken)
OPTIONS
GET
PROPFIND
HEAD
POST (/_api/web/GetFileByUrl(@v)/ListItemAllFields/GetSharingInformation) <- This I googled is a call to SharePoint, so it is ignored for now

In Word 2016 I am now able to do changes and save directly using WebDAV where it calls the following:

HEAD
LOCK (Refresh lock)
PUT

If I try and do the same with 365 I get an error saying the it couldn't succesfully save the data to the WebDAV path, and no calls were done using the WebDAV protocol. 
I also observe that if a leave the document open in 2016 it will constantly refresh the locktoken, where this never happens in 365, which all points in the direction the Word 365 "forgets" that it has gotten a lock or just don't understand the response from the locktoken.

Are there any documentation on what exactly 365 wants as a response to the different WebDAV requests. I have found a document the discripte the newest WebDAV protocol in Office, and here it looks like we do forfill the requriments, and as shown this also works just fine for Word 2016.

I am more than happy to apply more information if needed. 


 

[#2]

We ran into this also when a customer switched to office 365. We employ a webdav server that allow the users to checkout documents exclusively and save them back to the webdav system. But with office 365 Excel refused, because the file might be shared.

It is the call to _api/web/GetFileByUrl(@v) that spoils the flow. If Excel doesn't get some formatted response back (even though there is no prior indication of this being a SharePoint system), then it will block webdav saving.

We encountered something like this with Office 2007, and now the refusal to properly interoperate with standard systems is back again.

Fortunately if you can intercept these calls and send back a response a simple json response will do.

Content-Type: application/json; odata.metadata=minimal
{ 'value' : [] }

Now Excel 365 will assume there are no sharers, or that it legitimately cannot get that information and just uses the LOCK mechanism.

Happy webdav'ing.

[#3]

P.s. Forgot to mention.

The OPTIONS call to / of the system is back also. If your webdav system doesn't respond on root, then you will have to make up for that also, even if your sharing is not in the root.

Just like in the Office 2007 days. :(

[#4]

Another day, another Office unoptimization of interoperability.

Recently people using our webdav solution get blocked by the Office privacy settings for "optional connected experiences". No matter even if the site is under trusted sites or not. And no matter that if you are in an org where you can set these settings yourself when you visit the setting, the optional experiences are already set.

this is not at all mentioned in the Microsoft documents at https://learn.microsoft.com/en-us/deployoffice/privacy/optional-connected-experiences.

Nor probably does this happen when you access a Sharepoint site.

The sort of solution is to add the domain of the site in the inetcpl privacy settings.

However it seems that this panel reduces the domain to almost TLD level, so this can be unworkable for everyone.