Sun Java System Web Server 7.0 Update 7 Administrator's Configuration File Reference

Chapter 6 Syntax and Use of obj.conf

The obj.conf file contains directives for HTTP request processing. The obj.conf file is located in the instance_dir/config directory.

During Web Server installation an obj.conf file is created. If you configure multiple virtual servers using the Admin Console or CLI, separate obj.conf files may be created for each virtual server. These files are named virtual-server-name-obj.conf, where virtual-server-name is the name of the virtual server. The newly created virtual-server-name-obj.conf becomes functional. This can be verified from the server.xml, where the name of the functional obj.conf is updated.

When changes made through Admin Console or CLI does not impact the obj.conf, for example changing log-level, no new virtual server specific obj.conf files are created and the default obj.conf will be used for all the virtual servers of the configuration.

However, when changes made through Admin interface impacts the obj.conf, for example Java disabling, a new obj.conf file is created for each virtual server. The server.xml file is immediately updated to reflect the appropriate obj.conf file used for each virtual server. During Java disabling if there are two virtual servers, vs1 and vs2, two new virtual server specific obj.conf files are created, vs1-obj.conf and vs2-obj.conf. These new files are updated in the server.xml with the exact object-file used by these two virtual servers.

<object-file>vs1-obj.conf</object-file>

<object-file>vs2-obj.conf</object-file>

From this point onwards, the obj.conf file is neither updated, used, nor deleted. However, if the user wants to modify the obj.conf file for either of the two virtual servers, they should edit the respective file only and not the original obj.conf file.


Note –

When another new virtual server vs3 is added, a new vs3-obj.conf should be created, updated in the server.xml and become functional. However, this fails to happen and the existing obj.conf is shared by the vs3. This behavior is a known issue and is recorded as a bug CR 6754145.


When this document refers to obj.conf, it refers either to all obj.conf files or to the obj.conf file for the virtual server being discussed.

This chapter discusses the obj.conf directives; the use of Object, Client, If, ElseIf, and Else tags; the flow of control in obj.conf; and the syntax rules for editing obj.conf.

This chapter has the following sections:

Request-Handling Process Overview

When Web Server first starts up, it performs some initialization tasks and then waits for an HTTP request from a client (such as a browser). When the server receives a request, it first selects a virtual server. The obj.conf file of the selected virtual server determines how the server handles a request.

The obj.conf file contains a series of instructions known as directives that tell the server what to do at each stage in the request-handling process. These directives are grouped inside Object tags. Each directive invokes a function with one or more arguments.

Each directive applies to a specific stage in the request-handling process. For example, a directive that applies during the authorization stage in the request-handling process is an AuthTrans directive.

Stages in the Request-Handling Process

  1. AuthTrans (authorization translation)

    Verify the authorization information (such as name and password) sent in the request.

  2. NameTrans (name translation)

    Translate the logical URI into a local file system path.

  3. PathCheck (path checking)

    Check the local file system path for validity and check if the requestor has access privileges to the requested resource on the file system.

  4. ObjectType (object typing)

    Determine the Multipurpose Internet Mail Encoding (MIME) type of the requested resource (for example, text/html, image/gif, and so on), and establish other resource-specific settings.

  5. Input (prepare to read input)

    Select filters that will process incoming request data read by the Service step.

  6. Output (prepare to send output)

    Select filters that will process outgoing response data generated by the Service step.

  7. Route (request routing)

    Select the server to service the request.

  8. Service (generate the response)

    Generate and return the response to the client.

  9. AddLog (adding log entries)

    Add entries to log files.

  10. Error (error handling)

    Send an error message to the client and exit processing. This step is executed only if an error occurs in the previous steps.

Directives in obj.conf

The directives in obj.conf invoke functions known as Server Application Functions (SAFs). Each directive calls a function, indicating when to call it and specifying parameters for it.

The syntax of each directive is:

Directive fn="function" name1="value1"...nameN="valueN"

The value of the function (fn) parameter is the name of the SAF to execute. All directives must supply a value for the fn parameter; if there is no function, the instruction will do nothing. The remaining parameters are the arguments needed by the function, and they vary from function to function.

For example:

NameTrans fn="document-root" root="D:/Sun/webserver7/https-server/docs"

In this example, the directive is executed during the NameTrans stage of request processing, and invokes the document-root SAF to specify the document root directory for the server. The document-root SAF parameter root specifies the path to the document root directory.

Parameters can contain references to variables and expressions. The variables can be predefined variables, variables defined at request time using the set-variable SAF, or variables defined in server.xml. For more information on the set-variable SAF, see set-variable. For more information on defining variables in server.xml, see variable. For more information on expressions and variables, see Appendix A, Using Variables, Expressions, and String Interpolation.

The server is shipped with a set of built-in SAFs that you can use to create and modify directives in obj.conf. Chapter 7, Predefined SAFs and Filters in obj.conf discusses these SAFs in detail. You can also define new SAFs, as discussed in Chapter 2, Creating Custom Server Application Functions, in Sun Java System Web Server 7.0 Update 7 NSAPI Developer’s Guide.

The magnus.conf file contains Init directive SAFs that initialize NASPI plug-ins. For more information, see Chapter 5, Predefined SAFs in magnus.conf.

Objects in obj.conf

Directives in the obj.conf file are grouped into Object tags. The default object contains instructions to the server on how to process requests by default. Each new object modifies the default object’s behavior.

An Object tag may contain a name or ppath attribute. Either parameter can be a wildcard pattern. For example:

<Object name="cgi">
<Object ppath="/usr/sun/webserver7/https-server/docs/private/*">

The server always starts handling a request by processing the directives in the default object. However, the server switches to processing directives in another object after the NameTrans stage of the default object if either of the following conditions is true:

When the server is alerted to use an object other than the default object, it processes the directives in the other object before processing the directives in the default object. For some steps in the process, the server stops processing directives in that particular stage (such as the Service stage) as soon as one is successfully executed, whereas for other stages the server processes all directives in that stage, including the ones in the default object as well as those in the additional object. For more details, see Flow of Control in obj.conf.

Objects That Use the name Attribute

If a NameTrans directive in the default object specifies a name argument, the server switches to processing the directives in the object of that name before processing the remaining directives in the default object.

For example, the following NameTrans directive in the default object assigns the name cgi to any request whose URL starts with http://server_name/cgi:

<Object name="default">
NameTrans fn="pfx2dir"
          from="/cgi"
          dir="D:/sun/webserver7/https-server/docs/mycgi"
          name="cgi"
...
</Object>

When the NameTrans directive is executed, the server starts processing directives in the object named cgi:

<Object name="cgi">
...
</Object>

Objects That Use the ppath Attribute

When the server completes processing the NameTrans directives in the default object, the logical URL of the request has been converted to a physical path name. If this physical path name matches the ppath attribute of another object in obj.conf, the server switches to processing the directives in that object before processing the remaining ones in the default object.

For example, the following NameTrans directive translates the http://server_name/ part of the requested URL to D:/sun/webserver7/https-server/docs/, the document root directory:

<Object name="default">
NameTrans fn="document-root" 
          root="D:/sun/webserver7/https-server/docs"
...
</Object>

In this example, the URL http://server_name/internalplan1.html is translated to D:/sun/webserver7/https-server/docs/internalplan1.html.

However, if obj.conf contains the following additional object:

<Object ppath="*internal*">
   
</Object>

In this example, the partial path *internal* matches the path D:/sun/webserver7/https-server/docs/internalplan1.html. The server starts processing the directives in this object before processing the remaining directives in the default object.

Using the Client, If, ElseIf, and Else Tags

Additional tags are available to use within the Object tag. These tags give you greater flexibility when invoking directives within an object. This section contains the following sections:

Client

The Client tag enables you to limit the execution of a set of directives to requests received from specific clients. Directives listed within the Client tag are executed only when information in the client request matches the parameter values specified.

Client Tag Parameters

The following table lists the Client tag parameters.

Table 6–1 Client Tag Parameters

Parameter 

Description  

browser

The User-Agent string sent by a browser to the Web Server.

chunked

A Boolean value set by a client requesting chunked encoding. 

code

The HTTP response code. 

dns

The DNS name of the client. 

internal

The Boolean value indicating internally generated request. 

ip

The IP address of the client. 

keep-alive

The Boolean value indicating whether the client has requested a keep-alive connection. 

keysize

The key size used in an SSL transaction. 

match

The match mode for the Client tag. The valid values are all, any, and none.

method

The HTTP method used by the browser. 

name

The name of an object as specified in a previous NameTrans statement.

odds

A random value for evaluating the enclosed directive. The value can be a percentage or a ratio (for example, 20% or 1/5). 

path

The physical path to the requested resource. 

ppath

The physical path of the requested resource. 

query

The query string sent in the request. 

reason

The text version of the HTTP response code. 

restarted

A Boolean value indicating that a request has been restarted. 

secret-keysize

The secret key size used in an SSL transaction. 

security

Indicates an encrypted request. 

type

The type of document requested (such as text/html or image/gif).

uri

The URI section of the request from the browser. 

urlhost

The DNS name of the virtual server requested by the client (the value is provided in the Host header of the client request).

variable-headers

Prevents access to a specific site, based on the request by the client. For example, 

Client variable-headers="Weferer:SKVFVWRKJVZCMHVIBGDA
Service type="image/*" fn="deny-existence"
</Client>

The Client tag parameter provides greater control when the If directive is executed. In the following example, use of the odds parameter gives the request a 25% chance of being redirected:

<Client odds="25%">
NameTrans fn="redirect"
          from="/Pogues"
          url-prefix="http://pogues.example.com"
</Client>

One or more wildcard patterns can be used to specify the Client tag parameter values. Wildcards can also be used to exclude clients that match the parameter value specified in the Client tag. In the following example, the Client tag and the AddLog directive are combined to direct the Web Server to log access requests from all clients except those from the specified subnet:

<Client ip="*~192.85.250.*">
AddLog fn="flex-log" name="access"
</Client>

You can also create a negative match by setting the match parameter of the Client tag to none. In the following example, access requests from the specified subnet are excluded as are all requests to the virtual server sun.com:

<Client match="none" ip="192.85.250.*" urlhost="www.sun.com">
AddLog fn="flex-log" name="access"
</Client>

For more information about wildcard patterns, see Appendix B, Using Wildcard Patterns.

If, ElseIf, and Else

The If, ElseIf, and Else tags enable you to define the conditions under which to execute a set of directives. Like the Client tag, these tags can only appear inside an Object tag. In addition, these tags can evaluate an expression, then conditionally execute one or more contained directives. However, there are some key differences between the these tags and the Client tag, as summarized below:

When used, an ElseIf or Else tag must immediately follow an If or ElseIf tag. ElseIf and Else tags are skipped if the preceding If or ElseIf expression evaluates to logical true.

The following example shows If, ElseIf, and Else tag syntax:

<If $path eq "/">
<If $browser =~ "MSIE">
NameTrans fn="rewrite" path="/msie.html"
</If>
<ElseIf $browser =~ "Mozilla">
NameTrans fn="rewrite" path="/mozilla.html"
</ElseIf>
<Else>
NameTrans fn="rewrite" path="/unknown.html"
</Else>
</If>

This example presents a different page based on whether the browser is Microsoft Internet Explorer, Mozilla, or another browser.

Flow of Control in obj.conf

Before the server can process a request, it must direct the request to the correct virtual server. After the virtual server is determined, the server executes the obj.conf file of the specified virtual server. This section discusses how the server decides which directives to execute in obj.conf.

AuthTrans

When the server receives a request, it executes the AuthTrans directives in the default object to check if the client is authorized to access the server. If there is more than one AuthTrans directive, the server executes them in sequence until one succeeds in authorizing the user, unless one of them results in an error. If an error occurs, the server skips all other directives except for the Error directive.

AuthTrans directives work in conjunction with the PathCheck directives. The AuthTrans directive checks if the user name and password associated with the request are acceptable, but it does not allow or deny access to the request; that is done by the PathCheck directive.

The authorization process is split into two steps to incorporate multiple authorization schemes easily and provide the flexibility to have resources that record authorization information.

When a client initially makes a request, the user name and password are unknown. The AuthTrans directive gets the user name and password from the headers associated with the request. The AuthTrans and PathCheck directives work together to reject the request if they cannot validate the user name and password. When a request is rejected, the server displays a dialog box. The client includes the user name and password in the headers and resubmits the request.

NameTrans

The server executes a NameTrans directive in the default object to map the logical URL of the requested resource to a physical path name on the server’s file system. For example, the URL http://www.test.com/some/file.html could be translated to the full file system path:

/usr/sun/webserver7/https-server/docs/some/file.html

The server looks at each NameTrans directive in the default object in turn, until it finds one that can be applied.

Because the server might not execute all NameTrans directives, the order in which the directives appear is important. For example:

NameTrans fn="document-root"
          root="D:/sun/webserver7/https-server/docs"
NameTrans fn="pfx2dir"
          from="/cgi"
          dir="D:/sun/webserver7/https-server/docs/mycgi"
          name="cgi"

In this example, the directive that calls pfx2dir will never be executed because the previous directive always establishes the physical path name for the resource. For the /cgi prefix to work, the directive that calls pfx2dir must be moved before the directive that calls document-root.

If no directive sets the physical path name, the server translates the logical URL to a file system path relative to the document root. The document root is specified by the document-root element in server.xml. For more information on the document-root element, see virtual-server.

How and When the Server Processes Other Objects

As a result of executing a NameTrans directive, the server might start processing directives in another object. This happens if the NameTrans directive that was successfully executed specifies a name or generates a partial path that matches the name or ppath attribute of another object.

If the successful NameTrans directive assigns a name by specifying a name argument, the server starts processing directives in the named object (defined with the object tag) before processing directives in the default object for the rest of the request-handling process.

For example, the following NameTrans directive in the default object assigns the name cgi to any request whose URL starts with http://server_name/cgi/.

<Object name="default">
...
NameTrans fn="pfx2dir" 
          from="/cgi" 
          dir="D:/sun/webserver7/https-server/docs/mycgi" name="cgi"
...
</Object>

When the NameTrans directive is executed, the server starts processing directives in the object named cgi:

<Object name="cgi">

</Object>

When a NameTrans directive is successfully executed, there is a physical path name associated with the requested resource. If the resultant path name matches the ppath (partial path) attribute of another object, the server starts processing directives in the other object before processing directives in the default object for the rest of the request-handling process.

For example, assume obj.conf contains an object as follows:

<Object ppath ="*internal*">

</Object>

Consider that a successful NameTrans directive translates the requested URL to the path name D:/sun/webserver7/https-server/docs/internalplan1.html. In this case, the partial path *internal* matches the path D:/sun/webserver7/https-server/docs/internalplan1.html. Hence, the server will process the directives in this object before processing the remaining directives in the default object.

PathCheck

After converting the logical URL of the requested resource to a physical path name in the NameTrans step, the server executes PathCheck directives to verify that the client is allowed to access the requested resource.

If there is more than one PathCheck directive, the server executes all directives in the order in which they appear, unless one of the directives denies access. If access is denied, the server switches to executing directives in the Error section.

If the NameTrans directive assigned a name or generated a physical path name that matches the name or ppath attribute of another object, the server first applies the PathCheck directives in the matching object before applying the directives in the default object.

ObjectType

Assuming that the PathCheck directives approve access, the server next executes the ObjectType directives to determine the MIME type of the request. The MIME type has three attributes: type, encoding, and language. When the server sends the response to the client, the type, language, and encoding values are transmitted in the headers of the response. The type also frequently helps the server to determine which Service directive to execute to generate the response to the client.

If there is more than one ObjectType directive, the server applies all directives in the order in which they appear. However, once a directive sets an attribute of the MIME type, further attempts to set the same attribute are ignored. The reason why all ObjectType directives are applied is that one directive may set one attribute, for example type, while another directive sets a different attribute, such as language.

As with the PathCheck directives, if another object has been matched to the request as a result of the NameTrans step, the server executes the ObjectType directives in the matching object before executing the ObjectType directives in the default object.

Setting the Type by File Extension

By default, the server determines the MIME type by calling the type-by-extension function. This function instructs the server to look up the MIME type according to the requested resource’s file extension in the MIME types table. This table is created during virtual server initialization by the MIME types file (which is usually called mime.types). For more information, see Chapter 8, MIME Types.

For example, the entry in the MIME types table for the extensions .html and .htm is usually:

type=text/html  exts=htm,html

which indicates that all files with the extension .htm or .html are text files formatted as HTML, and the type is text/html.


Note –

If you make changes to the MIME types file, you must reconfigure the server for the changes to take effect.


Forcing the Type

If no ObjectType directive has set the type and the server does not find a matching file extension in the MIME types table, the type still has no value even after type-by-expression has been executed. Usually if the server does not recognize the file extension, it is a good idea to force the type to be text/plain, so that the content of the resource is treated as plain text. There are also other situations where you might want to set the type regardless of the file extension, such as forcing all resources in the designated CGI directory to have the MIME type magnus-internal/cgi.

The function that forces the type is force-type.

For example, the following directives first instruct the server to look in the MIME types table for the MIME type, then if the type attribute has not been set (that is, the file extension was not found in the MIME types table), set the type attribute to text/plain.

ObjectType fn="type-by-extension"
ObjectType fn="force-type" type="text/plain"

If the server receives a request for a file abc.date, it looks in the MIME types table, does not find a mapping for the extension .date, and consequently does not set the type attribute. As the type attribute has not already been set, the second directive is successful in forcing the type attribute to text/plain.

The following example illustrates another use of force-type. In this example, the type is forced to magnus-internal/cgi before the server gets a chance to look in the MIME types table. In this case, all requests for resources in http://server_name/cgi/ are translated into requests for resources in the directory D:/sun/webServer7/https-server/docs/mycgi/. As a name is assigned to the request, the server processes the ObjectType directives in the object named cgi before processing the ones in the default object. This object has one ObjectType directive, which forces the type to be magnus-internal/cgi.

NameTrans fn="pfx2dir" 
          from="/cgi" 
          dir="D:/sun/webserver7/https-server/docs/mycgi" name="cgi"
<Object name="cgi">
ObjectType fn="force-type" type="magnus-internal/cgi"
Service fn="send-cgi"
</Object>

The server continues processing all ObjectType directives including those in the default object, but as the type attribute has already been set, no other directive can set it to another value.

Input

The Input directive selects filters that will process incoming request data read by the Service step. Input directives are invoked when the server or plug-in first attempts to read entity body data from the client. You can add the NSAPI filters that process incoming data by invoking the insert-filter SAF in the Input stage of the request-handling process. NSAPI filters enable a function to intercept and potentially modify the content presented to or generated by another function. The Input directives are executed once per request.

The order of Input fn="insert-filter" and Output fn="insert-filter" directives in obj.conf is important if two or more filters are defined to occupy the same location in the filter stack. Filters that were inserted later will appear higher than filters that were inserted earlier.

Output

The Output directive selects filters that will process outgoing response data generated by the Service step. The Output directive allows you to invoke the insert-filter SAF to install NSAPI filters that process outgoing data. NSAPI filters enable a function to intercept and potentially modify the content presented to or generated by another function. Output directives are executed when the server or a plug-in first attempts to write entity body data from the client. The Output directives are executed once per request.

The order of Input fn="insert-filter" and Output fn="insert-filter" directives in obj.conf is important if two or more filters are defined to occupy the same location in the filter stack. Filters that were inserted later will appear higher than filters that were inserted earlier.

Route

If a Service directive requires that the HTTP request be sent to another server, the server executes Route directives to determine how the request should be routed. Routing a request can involve selecting the server that will ultimately service the request and selecting a proxy through which the request is sent.

Service

The server executes a Service directive to generate the response to send to the client. The server looks at each Service directive to find the first one that matches the type, method, and query string. If a Service directive does not specify type, method, or query string, then the unspecified attribute matches anything.

If there is more than one Service directive, the server applies the first one that matches the conditions of the request and ignores all remaining Service directives.

For the PathCheck and ObjectType directives, if another object has been matched to the request as a result of the NameTrans step, the server considers the Service directives in the matching object before considering the ones in the default object. If the server successfully executes a Service directive in the matching object, it will not execute the Service directives in the default object, because it only executes one Service directive.

Service Examples

Consider an example where the server receives a request for the URL D:/server_name/jos.html. In this case, all directives executed by the server are in the default object.

  1. The following NameTrans directive translates the requested URL to D:/sun/webserver7/https-server/docs/jos.html:

    NameTrans fn="document-root" 
    root="D:/sun/webserver7/https-server/docs"
  2. Assume that the PathCheck directives succeed.

  3. The following ObjectType directive tells the server to look up the resource’s MIME type in the MIME types table:

    ObjectType fn="type-by-extension"
  4. The server finds the following entry in the MIME types table, which sets the type attribute to text/html:

    type=text/html exts=htm,html
  5. The server invokes the following Service directive. The value of the type parameter matches anything that does not begin with magnus-internal/.

    Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" 
    fn="send-file""

    For a list of all wildcard patterns, see Appendix B, Using Wildcard Patterns.

Here is an example that involves using another object:

  1. The following NameTrans directive assigns the name personnel to the request.

    NameTrans fn=assign-name name=personnel from=/personnel
  2. As a result of the name assignment, the server switches to processing the directives in the object named personnel. This object is defined as:

    <Object name="personnel">
     Service fn="index-simple"
    </Object>
  3. The personnel object has no PathCheck or ObjectType directives, so the server processes the PathCheck and ObjectType directives in the default object. Assume that all PathCheck and ObjectType directives succeed.

  4. When processing Service directives, the server starts by considering the Service directive in the personnel object, which is:

    Service fn="index-simple"
  5. The server executes this Service directive, which calls the index-simple function.

    As a Service directive has now been executed, the server does not process any other Service directives. However, if the matching object did not have a Service directive that was executed, the server would continue looking at Service directives in the default object.

Default Service Directive

There is usually a Service directive that does the default task (sends a file) if no other Service directive matches a request sent by a browser. This default directive should come last in the list of Service directives in the default object to ensure that it only gets called if no other Service directives have succeeded. The default Service directive is usually:

Service method="(GET|HEAD|POST)" type="*~magnus-internal/*" fn="send-file"

This directive matches requests whose method is GET, HEAD, or POST, which covers nearly all requests sent by browsers. The value of the type argument uses special pattern-matching characters.

The characters *~ mean anything that does not match the following characters, so the expression *~magnus-internal/ means anything that does not match magnus-internal/. An asterisk by itself matches anything, so the whole expression *~magnus-internal/* matches anything that does not begin with magnus-internal/.

So if the server has not already executed a Service directive when it reaches this directive, it executes the directive as long as the request method is GET, HEAD, or POST, and the value of the type attribute does not begin with magnus-internal/. The invoked function is send-file, which simply sends the contents of the requested file to the client.

AddLog

After the server generates the response and sends it to the client, it executes AddLog directives to add entries to the log files. All AddLog directives are executed. The server can add entries to multiple log files.

Error

If an error occurs during the request-handling process, for example, if a PathCheck or AuthTrans directive denies access to the requested resource or the requested resource does not exist, the SAF sets the HTTP response status code and returns the value REQ_ABORTED. When this happens, the server stops processing the request. Instead, it searches for an Error directive matching the HTTP response status code or its associated reason phrase and executes the directive’s function. If the server does not find a matching Error directive, it returns the response status code to the client.

Changes in Function Flow

There are times when the function flow changes from the normal request-handling process. This happens during internal redirects, restarts, and URI translation functions.

Restarted Requests

Requests may be restarted. For example, a PathCheck directive might restart a request for http://server_name/ as a request for http://server_name/index.html.

Internal Requests

The server can generate internal requests. For example, an SHTML file or Servlet might include a file. While processing the original request, the server makes an internal request to retrieve this file.

URI Translation

The server can execute AuthTrans and NameTrans directives to translate a URI to a physical path name without starting a new request. For example, the server might execute AuthTrans and NameTrans directives in order to set the PATH_INFO_TRANSLATED CGI environment variable.

Editing obj.conf

Be very careful when editing this file. Simple mistakes can make the server fail to start or operate correctly.

Order of Directives

The order of directives is important, because the server executes them in the order in which they appear in obj.conf. The outcome of some directives affects the execution of other directives.

For PathCheck directives, the order within the PathCheck section is not so important because the server executes all PathCheck directives. However, the order within the ObjectType section is very important, because if an ObjectType directive sets an attribute value, no other ObjectType directive can change that value. For example, if the default ObjectType directives are listed in the following order (which is the incorrect way), every request will have its type value set to text/plain, and the server will not have a chance to set the type according to the extension of the requested resource.

ObjectType fn="force-type" type="text/plain"
ObjectType fn="type-by-extension"

Similarly, the order of directives in the Service section is very important. The server executes the first Service directive that matches the current request and does not execute the others.

Parameters

The number and names of parameters depend on the function. The order of parameters on the line is not important.

Case Sensitivity

Items in the obj.conf file are case-sensitive including function names, parameter names, parameter values, and path names.

Separators

The C language allows function names to be composed only of letters, digits, and underscores. You may use the hyphen (-) character in the configuration file in place of underscore (_) for your C code function names. This is only true for function names.

Quotation Marks

Quotation marks (“) are only required around the value strings when there is a space in the string. Otherwise, they are optional. Each open quotation mark must be matched by a closed quotation mark.

Spaces

Line Continuation

A long line may be continued on the next line by beginning the next line with a space or tab.

Path Names

Always use forward slashes (/) rather than backslashes (\) in path names on the Windows platform. A backslash escapes the next character.

Comments

Comments begin with a pound (#) sign. If you manually add comments to obj.conf, then use the Admin Console or CLI to make changes to your server, your comments are overwritten when obj.conf is updated.