"HTTPd Mapping Rules5

HFRD Hypertext Services - Technical Overview

p [next] [previous][contents]

5 - HTTPd Mapping Rules




G URLs paths are mapped to physical file system locations using mapping Ksimilar to other HTTPd implementations. HFRD's is based on the CERN HTTPd Jimplementation, with one additional script mapping rule. By default, the >system-table logical name HTTPD$MAP locates a common Kmapping rule file, unless an individual rule file is specified using a job-Ltable logical name. Simple editing of the mapping file changes the rules. DComment lines may be included by prefixing them with the hash ``#'' Ocharacter. Although, there is no fixed limit on the number of rules there are Bthe processing implications of scanning a large, linear database. 

D Rules are given a basic consistency check when loaded (i.e. server Jstartup, map reload, etc.) If there is an obvious problem (unknown rule, Lmissing component, etc.) a warning message is generated and the rule is not Lloaded into the database. This will not cause the server startup to fail. ?These warning messages may be found in the server process log. 

F A command-line rule checking utility is available for assessing rule Gdatabase files and the mappings generated against supplied paths. See ;7.2 - Mapping Rule Checker. 

J Any changes to the mapping file may be (re)loaded into the running HTTPd 9server using the following command on the server system: 

  $ HTTPD /DO=MAP


[ Also see 4 - HTTPd Configuration for daemon configuration. 

MAP, PASS, FAIL Rules


    &
  1. map template result

    D If the URL path matches the template, substitute the result >string for the path and use that for further rule processing. 

    !

  2. pass template (
    pass template result 

    L If the URL path matches the template, substitute the result if present (if Bnot just use the original URL path), processing no further rules. 

    F The result should be a physical VMS file system specification @in URL format. If there is a direct correspondance between the =template and result the result may be omitted. 

    - The PASS directive is also used to Ireverse-map VMS file specifications to the URL format equivalent. 

    !

  3. fail template 

    F If the URL path matches the template, prohibit access, processing no further rules. 



REDIRECT Rule



    2
  1. redirect template result

    D If the URL path matches the template, substitute the result Hstring for the path. Process no further rules. The result must Jbe a full URL (http://host/path), and is used to redirect requests &to another server on a separate host. 



I This will probably not be used extensively on the internal HFRD network. .

EXEC and SCRIPT, Script Mapping Rules



= Also see 6 - HTTPd Scripting.

) The EXEC rules maps CGI script directories.

3 The SCRIPT rules maps CGI script file ?names. It is a little different to the EXEC rule $and an extension to the CERN rules. 

? Both rules must have a template and result, and Nboth must end in a wildcard asterisk. The placement of the wildcards and the 7subsequent functionality is slightly different however.

    (
  1. exec template result 

    7 The EXEC rule requires the template's Casterisk to immediately follow the slash terminating the directory Nspecification containing the scripts. The script name follows immediately as 2part of the wildcard-matched string. For example:&

      exec /htbin/* /ht_root/script/*
    

    G If the URL path matches the template, the result, including the first Nslash-terminated part of the wildcard-matched section, becomes the URL format Jphysical VMS file specification for the DCL procedure of the script to be =executed (the default file extension of .COM is not Mrequired). What remains of the original URL path is used to create the path (information. Process no further rules. 

    : Hence, the EXEC rule will match multiple script Nspecifications without further rules, the script name being supplied with the JURL path. Hence any script (i.e. procedure, executable) in the specified Mdirectory is accessable, a possible security concern if script management is distributed.

    *

  2. script template result 

    9 The SCRIPT rule requires the template's Hasterisk to immediately follow the unique string identifying the Lscript in the URL path. The wildcard-matched string is the following path, *and supplied to the script. For example: ,

      script /conan* /ht_root/script/conan*
    

    I If the URL path matches the template, the result becomes the URL format Jphysical VMS file specification for the DCL procedure of the script to be =executed (the default file extension of .COM is not Mrequired). What remains of the original URL path is used to create the path (information. Process no further rules. 

    Note:

    JThe wildcard asterisk is best located immediately after the unique script Midentifier. In this way there does not need to be any path supplied with the Oscript. If even a slash follows the script identifier it may be mapped into a Cfile specification that may or may not be meaningful to the script.
     

    < Hence, the SCRIPT rule will match only the script Hspecified in the result, making for finely-granular scripting at Lthe expense of a rule for each script thus specified. It also implies that =only the script name need precede any other path information.

    K It may be thought of as a more efficient implementation of the equivalent Kfunctionlity using two CERN rules, as illustrated in the following example:!

      map /conan* /script/conan*"  exec /script/* /ht_root/script/*
    


Rule Interpretation




E The rules are scanned from first towards last, until a pass, Bexec or fail is encountered, when processing ceases Band final substitution occurs. Maped rules substitute the @template with the result and continue to the next rule. 

7 Use of wildcards in template and result:



The exampleLmapping rule file for the HFRDHTTPd server can be viewed. $

Examples of Map Rule



F The result string of these rules may or may not correspond to Nto a VMS physical file system path. Either way the resulting rule is further %processed before passing or failing. 

%

Examples of Pass Rule




G The result string of these rules should correspond to to a VMS physical file path. 

%

Examples of Fail Rule


 3

Examples of Exec and Script Rules


 )

Examples of Redirect Rule


 C

5.1 - Mapping User Directories (tilde character (``~''))


 

H This server will map user directories using the same mechanisms as for Many other. No reference is made to SYSUAF.DAT, user support is accomplished Ovia a combination of mapping rule and logical name. This approach relies on a Ocorrespondance between the user name and the home directory name. Hence users Mare made known by the HTTPd using the name of their top-level directory. As Mthe naming of home directories using the user name is a common practice this Kmechanism should suffice in the majority of cases. Where there is no such =correspondance individual rules could be used for each user. 

> The PASS rule provides a wildcard representation of Musers' directory paths. As part of this mapping a subdirectory specifically Dfor the hypertext data should be always included. Never map Fusers' top-level directories. For instance if a user's account home Bdirectory was located in the area USER$DISK:[DANIEL] the Lfollowing rule would potentially allow the user DANIEL to provide hypertext ?information from the home subdirectory [.WWW] (if the 1user has created it) using the accompanying URL: $

  pass /~*/* /user$disk/*/www/*  http://host/~daniel/


B It is recommended that a separate logical name be created Mfor locating user directories. This helps hide the internal organisation of Ithe file system. The following logical name definition and mapping rule illustrate this point. L

  $ DEFINE /SYSTEM /EXEC /TRANSLATION=CONCEALED WWW_USER DSA811:[USER.]  pass /~*/* /www_user/*/www/*


K Where users are grouped into different areas of the file system a logical search list may be defined. 6

  $ DEFINE /SYSTEM /EXEC /TRANSLATION=CONCEALED -           WWW_USER -           DISK1:[GROUP1.], -           DISK1:[GROUP2.], -           DISK2:[GROUP3.], -           DISK2:[GROUP4.]      pass /~*/* /www_user/*/www/*


K As logical search lists have specific uses and some complications this is Cthe only use for them recommended with this server, although it is Ispecifically coded to allow for search lists in document specifications. 

F If only a subset of all users are to be provided with WWW publishing Naccess either their account directories can be individually mapped (best used Lonly with a small number) or a separate area of the file system be provided 8for this purpose and specifically mapped as user space. 

K Of course, user mapping is amenable to all other rule processing so it is La simple matter to redirect or otherwise process user paths. For instance, Mthe published user name does not need to, or need to continue to, correspond ?to any real user area, or the user's actual name or home area: 5

  redirect /~doej/* http://a.nother.host/~doej/*+  pass /~doej/* /www/messages/deceased.html.  pass /~danielm/* /special$www$area/danielm/*/  pass /~Mark.Daniel/* /user$disk/danielm/www/*  pass /~*/* /www_user/*/www/*


H A user directory is always presented as a top-level directory (i.e. no Mparent directory is shown), although any subdirectory tree is accesssable by default.




p [next] [previous][contents]