Novell Home

My Favorites

Close

Please to see your favorites.

Cannot access NetStorage through iChain via windows network places

(Last modified: 02Mar2005)

This document (10096429) is provided subject to the disclaimer at the end of this document.

fact

iChain 2.3

iChain 2.3 Support pack 2 applied (2.3.268)

Apache Web server running NetStorage

NetDrive NetStorage client works fine

NetStorage access via browser works fine

NetDrive client running on Windows 2000 and XP

Secure exchange enabled or disabled makes no difference

symptom

Cannot access NetStorage through iChain via windows network places

Error: "The folder you entered does not appear to be valid"

Cannot view NetStorage files through iChain

fix

Apply proxy.nlm from iChain 2.3 build 2.3.269. This is the first build after iChain 2.3 Support Pack 2. After installing this build, modify the appstart.ncf file to load proxy with the -PTP ption. This allows the propagation of the Public header (see below) through the proxy.

The problem is that the NetStorage client generates and sends a WebDAV OPTIONS request to the back end Apache server WITH it's user agent set as WebDAV protocol discovery. The back end server responds to this OPTIONS request by sending back a list of WebDAV options it supports via a Public HTTP header.. The key option is the SEARCH option. iChain, as with any proxy following the HTTP RFC, strips out this Public header so the NetStorage client never gets the back end options. It then tries to use Frontpage extensions rather than WebDAV extension to do a protocol discovery, which fail as the back end Apache has no server for Frontpage queries.

iChain can address the issue by forwarding the Public header but this will break the RFC. All testing outside customer environment never shows up an OPTIONS request with the protocol discovery user-agent.

cause

Under the hood, Web Folders (My Network Places) employ a programming interface called the OLE DB Provider for Internet Publishing (for information, visit msdn.microsoft.com/library/sdkdoc/ipubsdk/ipub01_8kf6.htm), which maps requests made via the user interface into network protocol requests. Web Folders use either the IETF standard WebDAV protocol or the Microsoft FrontPage protocol to send Web Folder requests across the network to a remote server. When a Web Folder first contacts a Web server, it goes through a discovery process to select which protocol to use.

The first step in the protocol discovery is sending an HTTP OPTIONS request, the standard feature-discovery mechanism for HTTP. If the response contains the MS-Author-Via header (a nonstandard header) with the value MS-FP/4.0, it will use the FrontPage protocol; if it has the value DAV, it will use the WebDAV protocol. If the MS-Author-Via header is not present, Web Folders loads the FrontPage protocol driver (called the Web Extender Client, or WEC), and asks it if it can talk to the server. It does this by sending a GET /_vti_inf.html, followed by a POST /_vti_bin/shtml.exe/_vti_rpc (the _vti is a leftover from FrontPage's early development by a startup called Vermeer Technology). If the server responds incorrectly (such as with a 404 Not Found message), Web Folders next checks for WebDAV support by sending a second OPTIONS request. This time, if the DAV (a header all WebDAV servers must implement) is present, Web Folders will begin using WebDAV.

Now to our setup ... in the cases where we have everything working (in our test environment here), it's WebDAV traffic all the way and there are no requests for the dicovery process. In the traces from your setup where it is failing, I can see that

a) the options WebDAV request generated by the client always uses the protocol dicovery user-agent header

OPTIONS /oneNet/NetStorage/DriveG-DATA/USERS/ADDP/DSuski HTTP/1.0
Connection: keep-alive
Host: gnat.cpsc.gov
Translate: f
User-Agent: Microsoft Data Access Internet Publishing Provider Protocol
Discovery
Content-Length: 0
Authorization: Basic ZHN1c2tpOmpveWpydHIyMzQ=
Cookie: novellsession1=PMz7fpLYxAEBAAEBAQABGQ==
Via: 1.1 ics_server.cpsc.gov (iChain 2.3.245)

b) your browser then tries to generate GET and POST requests for the GET /_vti_inf.html, followed by a POST /_vti_bin/shtml.exe/_vti_rpc links mentioned above ie. it is trying to use the Frontpage protocol driver!

 

Looking at RFC 2068 the following appears to be happening.  The OPTIONS method allows the client to discover if a resource supports the SEARCH method and to determine the list of search grammars supported for that resource. The client issues the OPTIONS method against a resource named by the Request-URI (/onenet/NetSTorage in our case). If a resource supports the SEARCH method, then the server MUST list SEARCH in the OPTIONS response as defined by RFC2068. The Public header determines this but iChain (or any Proxy) is not forwarding the Public header. The end result is that the OPTIONS method, in discovery mode, does not get the SEARCH response it expects and then tries to use the Frontpage extensions we see above using the GET and POST queries.

If we can figure out why the browser client is using the "Microsoft Data Access Internet Publishing Provider Protocol Discovery" user-agent, then we will probably get to the bottom of this issue. All the options requests in our working setup use the Cache Manager user agent.

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.

  • Document ID:
  • 10096429
  • Solution ID: NOVL100804
  • Creation Date: 31Jan2005
  • Modified Date: 02Mar2005
    • NetIQiChain

Did this document solve your problem? Provide Feedback