help.axcms.netAxinom Logo
Save Save Chapter Send Feedback


AxCMSHttpModule handles every request in Live System and routes it to the right site and page, verifying user permissions if needed.

When you request page or document from browser by typing URL, then web server receive it, routes request to HTTP module if such defined. After that module is responsible for solving if this request can be assigned with any page or document that exists in or end up with some kind of error message that might be constructed and configured in MS.

In general whole resolving can be imagined as follow:

Next we will go through some parts more in depth to describe details of some processes.

Element resolving

There is standard mechanism for resolving element from URL – URL Resolvers. Read more about them

Error pages

In there is two general ways to define error pages.

  1. Use web.config keys to define default pages for non site specific environments (configurations will be used only in case if it was not possible to detect site).
    NB! Keys must be added under section “appSettings”;
  2. Use site specific settings to define specific pages for every site you host with (read more about how to setup AxSite -

Page must not include any additional GET parameters in the name. It may be either ASPX page, static HTML page or some particular page of the E.g. you can set it as “ErrorPage.aspx” or static “ErrorPage.htm” (in this case it must exist in the root folder of the site) or “ErrorPage.AxCMS” (AxCMS is default extension for solutions, but is configurable).

Error page is transferred on server side (you will not see any changes in URL) for all cases except login, where it just redirects to particular page.
During transfer or redirect special GET parameter “ReturnUrl” will be added with full URL to page that caused this error. This can help provide more detailed information to the user or enhance error logging.

Error page logic is valid only in the context of live system site. During the management of the pages you will not have such functionality and customized error display will be ignored.

Next diagram shows how the page lookup is proceeding.

NotFoundPage is displayed when it is impossible to find requested element in database and appropriate object was not created. Usually occurs when user misspelled the name or element was removed.

  1. web.config: <add key=" NotFoundPage" value=" NotFoundPage.AxCMS" />;
  2. site settings: “Page not found” field under Custom Pages.

ServerErrorPage this page will be displayed in case of server error on page. This situation usually comes up when exception occurs during the load of element. With configured exception logger exception will be written to the file or sent by email.

  1. web.config: <add key=" ServerErrorPage" value=" ServerErrorPage.AxCMS" />;
  2. site settings: “Server error” field under Custom Pages.

LoginPage is displayed when element is found, but marked as protected then it will require authentication. Mechanism for creating identity is developer responsibility and must be implemented in page source behind (see Protection section).

  1. web.config: <add key=" SitePermission_LoginPage " value=" LoginPage.AxCMS" />;
  2. site settings: “Login” field under Custom Pages.

NoAccessPage page is used for cases when denial of requested element needs to be provided. It’s common for situations when user has a user account but don’t have rights to some particular element then instead of requested element the NoAccessPage will be shown (see Protection section).

  1. web.config: <add key=" SitePermission_NoAccessPage" value=" NoAccessPage.AxCMS" />;
  2. site settings: “No access” field under Custom Pages.

Site detection

Before handler can proceed, with resolving the element and fill object with values from database, handler has to find out from what site request comes from and assign proper object to “NavigationContext.CurrentSite”.

Graphically process can be represented as follows:

Page handling types

Site lookup follow next algorithm to find proper site object:

  1. Check if “ActiveID” GET parameter is provided, which is navigation category ID and using its root can be found in navigation tree.
    All children nodes of SubTree Navigation are sites and going searching through tree we can find out under which site it is;
  2. Next try is to lookup site by host (iterating over all possible sites and try to match if any of the hosts are equal).
    NB! If element is not assigned to this site, then either element is page and next steps are rules by define handling type for this site or this element is document and NotFoundPage will be displayed;
  3. If page was found in database, but
    1. Site by host was found and handling type was set to Ignore;
    2. Site by host was not found;
    And page has some navigation nodes assigned (forward or backward assignment), then using them site can be detected. In case there is more than one site is detected first one taken from the list;
  4. If any of the previous steps was not successful, then site will be set as NULL.


Live site elements can be protected with security mode. More information can be found in dedicated article

You can think of handling types as of the instructions, which tell handler what to do in case when page was not found or don’t belong to the site.

  • Error – when page was not found in database or this element is not assigned to the current site, then NotFoundPage will be displayed;
  • Redirect – if page was found, but assigned to different site, then it will be redirected to first host of first site that this page has;
  • Switch – there is a possibility to enter site format (how the page names will look like specifically for this site). If page was found, but not assigned, then handler try to match similar page by format;
  • Ignore – all previous rules will be ignored and page served as is.

Document handling setup

Since Internet Information Service (IIS) server version 7 it automatically serve all request from to HTTP module that is defined in parent directory. So, when you have any requests to physical subdirectories of the site root, then it still try to resolve requests through module first.

In earlier versions subdirectories was handled as directories first and if module was defined in site root, then request to real subdirectories was not handled. To setup module handling for document upload path you will need to get through next steps:

  1. Open IIS Manager;
  2. Find your site;
  3. Click properties;
  4. Choose Home Directory tab;
  5. Click Configuration…;
  6. Add same executable path to wild card mapping as you have for AxCMS specific extension;
  7. Uncheck “Verify that file exists”;
  8. Ok and Apply.

Now all requests will be served through AxCMSHttpModule (defined in web.config) and documents will be checked for all handling rules too.

NB! You should now concern that having handling type set to Error and don’t assign page into proper navigation node will end up with NotFoundPage and e.g. images will not show up.