WebFolders Sharepoint Interaction

Document created by resplin Employee on Jun 6, 2015Last modified by alfresco-archivist on Aug 31, 2016
Version 2Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



Obsolete Pages
To find out how Windows Explorer (WebFolders) knows to handle Sharepoint (WebDAV) differently Ethereal was used to examine the HTTP traffic passing between the WebFolders client and Sharepoint server. This was then compared to the traffic between WebFolders and a normal WebDAV server.


Mapping a New Network Place


When going through the process of mapping a new network place PROPFIND requests are used to get the contents of the folder. This is the same for normal WebDAV servers and Sharepoint.

The Sharepoint server returns two Microsoft specific headers, 'MicrosoftTahoeServer' and 'MS-WebStorage'. It appears that the client upon recognising these goes about determining whether the server is Sharepoint by issuing a PROPFIND for /Sharepoint/system/schema.

As something meaningful is returned from this request (I presume) a number of SUBSCRIBE requests are sent to the server. I have no idea what this request does as it is not a standard WebDAV method and searching for it on Google and the Microsoft support site does not reveal anything useful.

Finally, a SEARCH request is performed which queries for lots of Sharepoint specific properties which obviously allows the client to display the relevant context options i.e. whether to show the checkin or checkout option.

POLL is another type of Microsoft specific request that sometimes appeared during the traffic monitoring, again I have no idea what this is and no documentation was found.

The conversation that occurs once the server is mapped just consists of PROPFIND and SUBSCRIBE requests.


Conclusion


From the traffic monitoring it appears that the WebFolders client knows to treat Sharepoint differently by combination of headers returned from the server and the results of a request for a Sharepoint specific file.

Therefore, it may be possible to fool the client into thinking it is talking to Sharepoint by returning the relevant headers and supplying the schema file from our repository server. However, there doesn't appear to be much documentation readily available so a lot of the requirements of the client will end up being a best guess, thus making the integration extremely brittle.

Outcomes