- Microsoft Windows SharePoint Services
- Microsoft SharePoint Portal Server
- Microsoft Exchange Web Store
- Microsoft Office Word 2003
- Microsoft Office Excel 2003
- Microsoft Office PowerPoint 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 associated MIME type that is specified in the HTTP header
- The CLSID as it is saved in a structured storage document
- The file name extension, if it is preserved in the URL string
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:
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:
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:
- Open the resource as read-only from the content that is downloaded by Internet Explorer. This content is opened in browse mode.
- Open the resource as read/write with a document lock on the server for exclusive access. This content is opened in edit mode.
- Web authoring protocol
If the server response provides either an MS-AUTHOR-VIA header value or a list of methods that are consistent with Distributed Authoring and Versioning, Office notes that the document can be saved back to the Web server by using the protocol that is specified.
The protocols that are currently available are Web Extender Client (WEC) and Web DAV. If the server does not provide a protocol, the file is considered read-only. The client can perform a SaveAs to save a copy locally. However a copy cannot be saved back to the folder where the file came from.
- Web-server type
Office also tries to determine the Web-server type. This determination is based on header information that is returned by the OPTIONS call. Specifically, Office looks for header values that indicate communications with a SharePoint document library or an Exchange WebStore folder. If communications are detected, Office performs additional communication to the server to enable the following Web collaboration features:
- Web discussion
- Task list updates
- Document check-out
- Document check-in
This is a 32-bit DWORD value that contains the Web authoring protocol to use for the document. The currently-defined values follow:
- 0 for read-only HTTP
- 1 for WEC to an FPSE-enabled Web folder
- 2 for DAV to a DAV-extended Web folder
This is a DWORD value that indicates the type of Web document collaboration server that manages the folder. The currently-defined values follow:
- 0 for no collaboration
- 1 for SharePoint Team Server
- 2 for Exchange 2000 Server
- 3 for SharePoint Portal 2001 Server
- 4 for SharePoint 2001 enhanced folder
- 5 for Windows SharePoint Server and SharePoint Portal 2003 Server
This is a 64-bit QWORD value that contains an expiration time. The value is a Win32 FILETIME structure that contains the expiration time in Universal Time Coordinate (UTC) format. After the expiration, Office re-queries the Web server with another OPTIONS call to make sure that the server configuration has not changed since the values were last cached. The length of the expiration time varies based on a random seed. The length of the expiration time is typically 2 weeks or longer.
Important The registry key is provided for informational purposes only. Do not edit the registry key or values directly. Office clears the cache periodically. Therefore, saved information is temporary.
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:
- Office Protocol Discovery uses a standard HTTP 1.1 OPTIONS command. Web servers that do not handle this command cannot support full read/write access in Office 2003. This is expected and is by design.
- You may be prompted for authentication when you open Office files. This behavior occurs if the Web server requires authentication to process an OPTIONS call to the URI of the folder. Changes to the server configuration can typically be made to avoid this problem by giving anonymous users browse permissions to the folder. Browse permissions are also know as list permissions. The prompt for authentication is expected if the server requires authentication.
- You may be prompted to select a client certificate or to select a trust-a-server certificate on open. This behavior may occur even if this certificate information is previously provided to Internet Explorer for the same navigation. Because Office makes a new request for its own process space to the server, a new session is created every time. This new session may produce additional security warnings or additional prompts to complete the OPTIONS call successfully.
- Cookie information that is used for gathering the document is not used in the OPTIONS request. If the server does not permit direct calls to the folder URL without this cookie information, the OPTIONS call may not be successful. If this problem occurs, the user may be prompted repeatedly for authentication, but the user may not be able to provide authentication. This is not because of missing authentication. This problem occurs because of missing session cookies for the Web server. This problem is specific to certain Web-server designs that depend on cookie information instead of authentication information or that depend on cookie information plus authentication information.
- There is a known problem with network configurations that use a Cisco Content Server Switch (CSS) load balancer with layer 5 filtering in their intranet environment. The CSS software does not correctly handle the HTTP 1.1 OPTIONS command. The CSS software does not forward the call to the Web server. Also, the CSS software does not return a response to the client that indicates an error and then closes the TCP connection.
Because the TCP packet is never acknowledged by the server, the client believes that the server has not received the message. Therefore, the client resends the message. Office continues sending this message and waiting for a response until the TCP connection eventually times out. This can cause a client to stop responding when opening an Office file. The Office application waits for the server response. The server response is never received because the CSS load balancer drops the TCP packet.
Cisco knows about this problem. Cisco is working on an update to resolve the issue. To work around this problem without the update, you can lower the CSS filtering to level 3 rules or to level 4 rules. You can also bypass the load balancer by changing the URL that is opened so that the URL points directly to the Web server that holds the content.
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:
- A user clicks a hyperlink in an Office document
- A document contains content that is based on a URL resource that may perform navigation
For more information, click the following article number to view the article in the Microsoft Knowledge Base: