Article ID: 838028 - View products that this article applies to.
This article describes the process that is used by Microsoft Office 2003 to open Microsoft Office Word 2003 documents, Microsoft Office Excel 2003 spreadsheets, and Microsoft Office PowerPoint 2003 presentations by using hyperlinks or Web folders in Microsoft Internet Explorer. The process involves several additions that have been made to enhance Web collaboration. These additions may affect existing Web solutions that rely on previous Office behavior. The information that is provided is for Web solution developers who want a better understanding of the technical process that Office uses to handle document downloading and editing from an HTTP resource.
Office 2003 is designed to make a more collaborative workspace. Therefore, several changes have been made to how Office 2003 works with Web content. These changes help to build Web solutions that make Office documents fully compatible with the Office 2003 system. This article describes these changes from a technical perspective. These changes provide better authoring features for the following Web servers that support Office 2003:
Hyperlinking in Office 2003 by using HLINK and URLMONLike earlier versions of Office, Office 2003 implements hyperlinking behavior by using the publicly exposed OLE interfaces of the URL Moniker component (Urlmon.dll) from Internet Explorer. The API that is provided by URLMON lets Office treat a URL resource as any OLE link source is treated by Office. Additionally, the URLMON API also provides methods for asynchronous navigation, for redirection, and for content sharing between processes.
To handle navigation history and backward capabilities, Office uses the public interfaces of the Microsoft Hyperlink Library (Hlink.dll) to create hyperlinks, to bind to hyperlinks, and to move to hyperlinks. HLINK is high-level wrapper for the features that are exposed by URLMON. HLINK gives Office applications a common framework to handle the basic tasks of hyperlink behavior.
Opening an Office document from Internet ExplorerWhen you click a hyperlink to an Office document from a Web page in Internet Explorer, the host frame navigates to the hyperlink resource by using URLMON. URLMON downloads the file content by using an HTTP GET command. After URLMON obtains the resource, URLMON looks at any one of the three following locations to identify the content type:
The full process of loading from a moniker and then using HLINK and URLMON to bind to Web content is beyond the scope of this article. For more detail on the programming aspects of this process, see the documentation on the Microsoft Developer Network.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
178853There is one critical drawback to this approach. URL monikers that are provided by Internet Explorer are typically read-only. You can open content and modify content, but you cannot save content back to the server. When you save content back to the storage that is provided by the moniker, the modifications are applied to the content in the Internet Explorer Temporary Internet Files cache. However, the modifications are not applied to the content on the Web server. To resolve this drawback, the concept of the publishing moniker is introduced in Office 2000 and later.
(http://support.microsoft.com/kb/178853/ )HLINKAXD demonstrates a hyperlinking active document
Making a URL moniker have read access and write access by using MSDAIPPWith the introduction of Office 2000, the capabilities of URLMON are extended to support full write access to a publishing server that supports either FrontPage Server Extensions (FPSE) or the HTTP 1.1 command extensions for Web Distributed Authoring and Versioning (DAV).
Support for full write access is completed by using a protocol provider extension to URLMON. The protocol provider extension to URLMON permits binding through a component that is named the Microsoft OLE DB Provider for Internet Publishing Provider (Msdaipp.dll). By using a set of flags to URLMON, a host can request binding by using a specialized URL moniker type that uses MSDAIPP. Office refers to this as a publishing moniker. The publishing moniker uses MSDAIPP to open and to save the content directly on the server. This is an important step to extend the capabilities of URLMON.
However, there is a drawback. The MSDAIPP component uses its own session of the Windows Internet (WININET) API, not the session in use by Internet Explorer itself. Therefore, non-persisted session information, such as server cookies, is unavailable in MSDAIPP requests. This makes some servers require re-authentication or re-navigation to the URL for MSDAIPP to communicate with those servers. Additionally, to avoid obtaining "stale" data that may have been changed by another user, MSDAIPP re-acquires the Web content after successfully locking the Web content for write access. This causes a second HTTP GET request or a second FPSE POST request to the Web server for the document content.
To work around this drawback, a modified approach is introduced in Office 2000 Service Release 1. Instead of trying to bind by using a publishing moniker at load time, Office binds to the document by using the typical read-only URL moniker that is provided by Internet Explorer. When you want to save the file, Office tries to switch to the publishing moniker to perform a save back to the server, if the server supports Web publishing. If re-authentication is required because of the change in session, you are prompted for credentials on save instead of on open. If you want to read the file without saving the file, Office avoids the costly switch-of-context to a publishing moniker. Office also avoids a server lock on the resource. This is a compromise approach.
For more information about some of the changes that have been made to Office 2000 Service Release 1 to mitigate the effects of opening Web documents by using the publishing moniker context, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/185978/ )Double GET requests and cookies are lost with Word 2000 or Excel 2000
(http://support.microsoft.com/kb/266263/ )BUG: Word 2000 and Excel 2000 display ASP source when using MIME type to stream data
(http://support.microsoft.com/kb/247318/ )BUG: Word 2000 and Excel 2000 do not redirect correctly when using Response.Redirect
(http://support.microsoft.com/kb/264143/ )FIX: ASP session variables empty when Office 2000 MIME types are streamed with Internet Explorer
Recognizing drawbacks with the approaches that are used by previous Office versionsThe compromise approach that is used by Office 2000 Service Release 1 and by Office XP is well suited for browsing documents and for saving these documents to the server. However, the compromise approach has drawbacks. The drawbacks become more noticeable as Web developers build more sophisticated Web-based document management systems that are meant to more seamlessly integrate with Microsoft Office.
The most important drawback is delaying the switch-of-context until after a user tries to save or to perform some explicit action that requires write access. The document resource is not locked and may be changed by another user or another process during the time that the first user has the file open. If the first user then tries to save, the changes of the second user are lost. Alternatively, the first user is faced with the choice of discarding their changes without knowing what the second user has changed.
Another drawback occurs because the author permissions of the user are unknown until the switch-of-context occurs. The user is not notified that they do not have permission to save the file until the user makes the actual request to save the file. The user must be notified that they do not have permissions to save the file before the file is opened for editing. This is the drawback that lead to the approach that is taken in Office 2000 Service Release 1.
Identifying changes to the hyperlink process for Office 2003There are a growing number of users who are using Office as a front end for document collaboration over HTTP intranets. Therefore, the drawbacks of the previous approach are acute. Changes are required to detect the difference between a shared document and a browsed document. Office 2003 introduces new features to the hyperlinking process to work around the drawbacks.
Understanding Microsoft Office Protocol DiscoveryWhen an Office application receives a request to open a Web resource, the Office application has to make the following decisions about how to open the Web resource:
The Server Cache contains sub-key entries for each Web folder that is opened and that has successfully returned an OPTIONS call. Each entry contains the following values set to the appropriate setting for that folder:
Identifying known drawbacks that are caused by Office Protocol DiscoveryOffice Protocol Discovery resolves the most important drawback, and that is to determine if the document must be opened as a read-only document or as a read/write document on the server. However, Office Protocol Discovery has the potential for some new drawbacks. The following problems are known side-effects of the current design:
The benefits that are gained by Office Protocol Discovery outweigh the currently known drawbacks. We believe these issues will decrease over time. We will continue to follow the last two problems to make sure that solutions are available if the existing network design cannot be adjusted. We believe the choice to use Office Protocol Discovery is the correct long-term strategy for Web collaboration.
Understanding HTTP conversion for UNC redirector filesClients 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.
Understanding Hyperlink zone security and security promptsOffice 2003 uses enhanced-security measures for Internet hyperlinking from links in the Office document. This includes passing security credential information under a more restrictive security zone policy so that Internet Explorer can permit or can deny passing credentials to the server. Permission or denial is based on the zone settings that are set for the user.
Also, Office 2003 makes sure that when navigation is under user control, WININET has a correct window handle. This means that WININET can raise security prompts to the user if prompts are required to perform an action. This enhances Web security in Office. However, tighter restrictions for Internet Explorer security zones may cause alerts to appear that did not appear in older versions of Office. The alerts appear during hyperlink navigation.
Additionally, Office 2003 adds an additional warning prompt under the following circumstances:
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/829072/ )How to disable hyperlink warning messages in Office 2003
For additional information about the OPTIONS command and the HTTP 1.1 protocol, see the HTTP Working Group Request for Comments (RFC) specification #2616 at the following Internet Engineering Task Force Web site:
http://www.ietf.org/rfc/rfc2616.txtFor more information about hyperlink issues in earlier versions of Office, click the following article numbers to view the articles in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/297891/ )You experience performance and memory problems when you switch between a Web browser and the Office XP programs
(http://support.microsoft.com/kb/810360/ )BUG: Word 2000 and Excel 2000 do not retain cookie information when you move to a hyperlink in the same session
(http://support.microsoft.com/kb/225234/ )You are prompted for a password when you open an Office 2000 document in a browser
(http://support.microsoft.com/kb/314400/ )You are unnecessarily prompted for your password when you follow a hyperlink in an Office document
(http://support.microsoft.com/kb/218153/ )Error message when clicking a hyperlink in Office: "Cannot locate the Internet server or proxy server"
(http://support.microsoft.com/kb/280680/ )Cannot follow hyperlink to Office document
Article ID: 838028 - Last Review: July 2, 2004 - Revision: 1.3