## Internet Search Path

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.

### Internet Search Path syntax

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.

### Object Stores

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=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:

- If CLSID is provided with no version number, then the most recent object matching the CLSID will be returned. If the CLSID is provided with Version, then the object matching the CLSID and with the largest version number greater than or equal to Version will be provided. If no object is available that matches the CLSID with a large enough version number, then the 404 error will be returned. MIMETYPE will be ignored when CLSID is provided.
- If no CLSID is provided, but MIMETYPE is provided, then the first object found in the database that matches the MIMETYPE will be returned. Version, if provided, is treated exactly as above. If neither CLSID or MIMETYPE is provided then the error return code 400 Bad Request will be returned.

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.

### Uses for Internet Search Path

The Internet Search Path can be used in two ways:

1. Object Store servers at the beginning of the path will be asked for code before checking the location specified in the szCodeURL parameter for CoGetClassObjectFromURL. Servers at the beginning of the search path will thus be checked before trying the location specified in the CODEBASE attribute of an <OBJECT> tag. This is a useful feature for corporate intranets, because it allows intranet administrators to set up a local Object Store that is used to serve code for download by employees. (in fact, it is possible to disable the CODEBASE attribute for <OBJECT> tags by removing the CODEBASE keyword from the search path.
2. "Object Store" servers at the end of the search path will be asked for code after trying the location specified in the szCodeURL parameter for CoGetClassObjectFromURL, and thus after trying the location specified in the CODEBASE attribute. This allows registration of default Object Store locations on the World Wide Web, where browsers can find code when no CODEBASE location is explicitly specified.

© 1996 Microsoft Corporation