Host Default-Page Precedence
Each IIS server is configured to resolve direct references to folders by searching for a default page within the folder. With IIS, the search order is controlled separately for each subweb, and each can have its own default-page precedence rules.
The Compagno configuration for development of Centrale sites is hosted on IIS 5.1 under Microsoft Windows XP Pro. Each site-development subweb can be adjusted so that access on Compagno matches the host-service default-page behavior. That leaves open the question of what an individual hosting service provides.
To test the hosting service, typically also an IIS server, I upload a set of potential default pages and see which one is served up. Then I delete that one and see what comes to the top next. That's the drill. Eventually I will be left with a set of pages that are not recognized as defaults and cannot be used. I will, however, have established what the server response for access to the index of a directory is.
1. Determining Precedence
2. Precedence Convention
3. Missing-Default Treatment
4. Open Questions
This section has the following potential default pages:
The actual precedence on the hosting site was determined by uploading a full set of self-identifying versions for each page. A browser was directed to the URL of the directory to see which page is presented by default. Each time the browser presented a given file, it was deleted on the server and the URL refreshed in the browser. This was done until the server no longer provided a default page. In the above list,
#1has precedence over all other default candidates, whether or not they are present. Likewise,
#5will only be presented if no other default is available.
In the absence of a default page, the server presents the following message for this directory:
Based on the precedence already provided at the hosting site, the development-site precedence was altered to match. This description is updated to reflect that precedence and to also be useful in detecting that hosting-site precedence has not changed.
In addition, the following conventions are used for all pages anchored on nfoCentrale:
default.htmwill always be used if present. None of the lower-precedence pages will be displayed as the default page even if they are there. They can be explicitly accessed however. For orcmid, this default page is reserved for when we want to intentionally block visibility of a
default.asp. This page has been used in the past as a standard default without consideration of having a default.asp page. We will end that practice and make
default.aspinstead, whether or not there is any ASP processing required.
is the next lower level of precedence. This file name is not used in ordinary sections.
is next in order of usage. Generally, this means that a
default.htmpage should not be employed if there is a chance that a
default.asppage will also be introduced and be intended to have the highest precedence. Since this is the only
.aspdefault page, this is always reserved for that use, with
default.htmintroduced only when we want to block or obscure a
is the next-lowest-precedence default page of all. It is used only for default or explicit entry to the construction structure of a web section.
is the lowest-precedence default page. Although there might be some value in using it, the convention here is to use only
index.htmin ordinary sections
There are also pages that this server does not recognize as default pages. In particular,
default.aspx is not recognized as a default page.
The Centrale web sites do not allow access to directories that have no default page. Instead, the server presents an error page.
It is the practice with this site to never provide such an error message for normal Web requests. Instead, there is always a default page in every reachable section. That page might present an HTTP error condition, or it might make a default presentation. A default-page announcement about the inaccessibility of content is usually provided using an
Although the use of this default scheme is sufficient for providing two or three levels of access to default pages, there are additional questions that remain to be resolved:
Can the default-page precedence of the anchor site be controlled by virtue of its support for FrontPage extensions, or any other way?
Can the error responses and the content of error-response message from the hosting server be controlled as part of the service?
Can ISAPI filtering be instituted, and can executables and scripts be introduced for full ASP functionality?
Can Web Service requests be intercepted and masked or accepted?
What is the impact of SSL usage on the treatment of default pages and also the use of cloaking?
nfoCentrale.nethost used to anchor Orcmid's Lair and other sites.
|You are navigating Orcmid's Lair||
created 2003-12-13-15:14 -0800 (pst) by orcmid