Our client has recently moved to a new SharePoint 2013 farm from another SharePoint 2013 farm trying to fix corruption on the web front end. Some servers from the old farm were used in the new farm. In doing this move, there have been several issues. The most pressing is that WebDav is not working on SharePoint document libraries.
In comparing Fiddler requests/responses with a working WebDav SharePoint 2013 environment, we have found that PROPFIND request to the library URL, result in redirect responses to the "Forms/AllItems.aspx" page which is not what we want. It seems like there is some server-side setup that is messed up.
Here is the request with the Host and Authorization headers removed:
PROPFIND http://somedomain.com/Lists/SomeDocuments HTTP/1.1 User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7601 Depth: 0 translate: f Connection: Keep-Alive Content-Length: 0
Here is the entire response:
HTTP/1.1 302 Redirect Content-Type: text/html; charset=UTF-8 Location: http://somedomain.com/Lists/SomeDocuments/Forms/AllItems.aspx Server: Microsoft-IIS/8.0 X-SharePointHealthScore: 0 SPRequestGuid: 5d80019d-bb49-5008-c154-025bfa963df1 request-id: 5d80019d-bb49-5008-c154-025bfa963df1 X-FRAME-OPTIONS: SAMEORIGIN SPRequestDuration: 28 SPIisLatency: 0 Persistent-Auth: true X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 22.214.171.12469 X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly Date: Wed, 29 Apr 2015 15:43:35 GMT Content-Length: 188 <head><title>Document Moved</title></head> <body><h1>Object Moved</h1>This document may be found <a HREF="http://somedomain.com/Lists/SomeDocuments/Forms/AllItems.aspx">here</a></body>
Note that the "/Lists" in front of the document library in the URL is there on purpose. The libraries were set up this way and WebDav was working with this setup prior to moving from one farm to another.
Any suggestions would be most appreciated!
UPDATE: When looking at the authentication provider (in the Default zone), it is just using Windows auth (NTLM) and we have "Require Use Remote Interfaces permission" checked as well as "Enable Client Integration" set to "yes". We have been testing with a site collection administrator, so it should have the remote interfaces permission.