How Office detects that a UNC path is really a WebDAV URL

This is a bit off topic, but when I received this question I realized that we don't have the answer available anywhere so I wanted to post it just in case other folks were interested. Here is the question:

Please forgive this random email, but I'm desperately trying to find out how Office knows when it has opened a UNC path which is really a WebDAV URL exposed by the XP mini-redirector, as described by the KB excerpt below. If you have any information about this or can point me to someone who does, I would be very grateful!

KB Article:

"Understanding HTTP conversion for UNC redirector files --
Clients that are running Windows XP Professional can create Network
Places to DAV Web folders by using the Web Client service. The Web
Client service is also known as the WebDAV mini-redirector. This Web
Client service lets DAV-enabled folders appear as UNC shares.
An application can open the file, edit the file, and save to the file
because the application typically saves to a UNC path. However, document
collaboration requires more functions than are provided by the Web
Client service. Therefore, Office 2003 has added code to determine if a
file is opened by the Web Client service. If a file is opened by the Web
Client service, Office 2003 re-maps the path back to a full URL and then
opens the file separately by using the protocol that is appropriate for
the server type. This lets an Office 2003 application perform
full-document collaboration features, as if the file is opened directly
from the URL in Office. The information that is provided previously,
including Office Protocol Discovery, applies to documents that are
opened from a Web Client-enabled UNC share."

In Office, we call WNetGetResourceInformationW on the UNC path to get the UNC Provider name for which network provider owns the file (returned in the lpProvider name string). We then compare that to the name of the Web Client MiniRedir service (retrieved via the WNetGetProviderNameW API for WNNC_DAV). If the providers match, we know we are activated on a UNC path owned by the Web Client DAV provider and can then opt-out appropriately (back to the core Office HTTP stacks).

-Brian

Comments

• Anonymous
  February 17, 2006
  I love lore like this.  It raises further questions for me, and some tips on finding the result would be handy.
  
  1. I assume that when Office determines that using the URL may be more profitable than staying with the UNC, that it tries all of the usual suspects: FrontPage extensions, DAV, maybe ftp, etc.  Is that still true.
  
  2. Are ODMA references put through something similar or is it still not part of a fully-common stack (or is it still in the 2007 Office System at all).  I have a personal interest in that question, although the answer probably won't influence what I'm doing right now.
• Anonymous
  February 22, 2006
  I'm not sure exactly what you mean when you say "the URL may be more profitable than staying with the UNC". For Office 2007, we will still support FPSE-RPC (FrontPage server extensions protocol), DAV (which is now our preferred method of communication), FTP, and vanilla HTTP/S GETs (where we are basically simulating a browser to get Read-Only access to the URL contents) to open files from URLs.  We also support browsing FPSE-RPC sites and DAV sites and FTP sites.
  
  There are some differences though when you get into Office 2007 running on Windows Vista.
  
  We also still support ODMA in all the same applications Office 2003 does (I believe that's Word, PPT & Visio). The ODMA stack is the same it has always been.  We respect the ODMA guidelines and load the ODMA provider installed on the machine, and use that provider to handle the browse and file i/o operations.
  
  -Brian
• Anonymous
  February 26, 2006
  Oh, "by more profitable" I meant that there may be more functionality available than when the UNC path is used as given.  Sorry for the clumsy wording.
• Anonymous
  February 27, 2006
  And the ODMA mention (since ODMA is much on my mind from time to time) was inspired by the mention of UNCs.  Because ODMA Document IDs always begin with "::" it seemed to me that the same stack for reconciling and optimizing UNCs [that is, finding an appropriate access method] might be used to handle ODMA Document IDs too.
  
  I was reading too much into it.  I also recognize that the ODMA case is a bit hairier than that.  Sounds like something to be left in the if it's not broken, don't fix it category.
  
  It's nice to see the emphasis on DAV.
• Anonymous
  May 09, 2006
  What office applications will have ODMA support in office 2007?
  What other methods can be used to integrate with office (preferably via com or code not macro's)?
• Anonymous
  June 28, 2006
  WebDAV supports the use of alternative ports for files like
  http://myserver:8080/myfile.xls
  Can a port be expressed in un UNC path?
  :-? stw
• Anonymous
  August 12, 2006
  Stephan,
  
  While the WebDAV spec may support alternate ports, the Web Client Service in Windows XP and Windows Server 2003 does not.
  
  Steve
• Anonymous
  August 14, 2006
  Hi Steve,
  
  that is strange, could you elaborate on that? When I create a new web folder and specify a port or I open a document in MS Office specifying the URL with port it actually works. I can load AND save the document. I also get a proper webDAV "conversation" with OPTIONS LOCK GET POST etc.
  So somehow it figures it out.
  :-) stw