When Internet Component Download is called to download code, it traverses the Internet Search Path to look for the desired component. This path is a list of Object Store servers that will be queried every time components are downloaded using CoGetClassObjectFromURL. This way, even if an <OBJECT> tag in an HTML document does not specify a CODEBASE location to download code for an embedded OLE Control, the Internet Component Download will still use the Internet Search Path to find the necessary code.
The search path is specified in a string in the registry, under the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\CodeBaseSearchPath. The value for this key is a string in the following format:
CodeBaseSearchPath = URL1; URL2; ... URLm; CODEBASE; URLm+1; ... URLn-1; URLn
Where each of URL1 through URLn are absolute URLs pointing to HTTP servers acting as "Object Stores". When processing a call to CoGetClassObjectFromURL, the Internet Component Download service will first try downloading the desired code from the locations URL1 through URLm, it will then try the location specified in the szCodeURL parameter (corresponding to the CODEBASE attribute in the <OBJECT> tag), and will finally try the locations specified in locations URLm+1 through URLn.
Note That if the CODEBASE keyword is not included in the CodeBaseSearchPath key, then calls to CoGetClassObjectFromURL will never check the szCodeURL location for downloading code. By removing the CODEBASE keyword from the CodeBaseSearchPath, corporate intranet administrators can effectively disable Internet Component Download for corporate users.
An Object Store on the Internet Search Path is an HTTP server that services requests for downloadable code(12). During a call to CoGetClassObjectFromURL, Internet Component Download will try to download code from the various Object Stores on the search path. Specifically, an Object Store will receive an HTTP POST request with data in the format below(13).
CLSID={class id}
Version=a,b,c,d
MIMETYPE=<e>mimetype
All the values above are optional, although one of CLSID or MIMETYPE must be present. The Object Store should parse this information, check an internal database, and either fail the call, or redirect the HTTP request to the download-able code Cabinet file (.CAB), setup script (.INF), or portable executable (.EXE/.DLL/.OCX).
The POST parameters should be processed by the Object Store as follows:
In addition to the POST data described above, queries to Object Stores will also include HTTP headers for Accept (MIME type) and Accept-Language, thus specifying the desired platforms (see above for Platform Independence and HTTP) and language-localized implementation for a component. Note that these HTTP headers are added to all HTTP requests made by Internet Component Download. This allows Object Stores to serve different code implementations for differing platforms or even different languages.
Note Internet Component Download will use the first successful response from a server on the Internet Search Path. Component Download will not continue searching for newer versions of components.
The Internet Search Path can be used in two ways: