Release 1 (v1.0.2.2)
Part Number A90099-01
 Contents |
 Index |
| Oracle9i Application Server Using the PL/SQL Gateway Release 1 (v1.0.2.2) Part Number A90099-01 |
|
Oracle9i Application Server consolidates Oracle's middle-tier products into a single solution for the deployment of Web applications. The PL/SQL Gateway provides support for building PL/SQL-based applications on the Web. PL/SQL stored procedures can retrieve data from a database and generate HTTP responses containing data and code to display in a Web browser. The PL/SQL Gateway also supports other Oracle products such as Oracle Portal.
The PL/SQL Gateway has two versions. The first involves mod_plsql, which is an Apache plug-in used to communicate with the database. It maps browser requests into database stored procedure calls over a SQL*Net connection. It is generally indicated by a /pls virtual path.
The second version involves the use of mod_ose. There is an embedded PL/SQL Gateway that is shipped with mod_ose.
The following scenario provides an overview of what steps occur when a server receives a client request:
The procedure that the PL/SQL Gateway invokes returns the HTTP response to the client. To simplify this task, the PL/SQL Gateway includes the PL/SQL Web Toolkit, a set of packages (also called the owa packages) that you can use in your stored procedure to get information about the request, construct HTML tags, and return header information to the client. Install the toolkit in a common schema so that all users can access it.
The use of mod_plsql or mod_ose determines which mode (stateful or stateless) is appropriate for you.
| mod_plsql | mod_ose |
|---|---|
|
Stateless (Reset Package - used for Oracle Portal) |
Stateful |
|
Stateless (Preserve Package - Applications) |
|
In this mode, mod_plsql calls dbms_session.reset_package after each request to clear all OWA packages and any application-specific variables and cursors. Furthermore, an implicit commit is done if there are no errors in processing the request.
PL/SQL applications are not responsible for cleaning up after the request is done. With each request, they are starting in a clean session which the mod_plsql is responsible for. This mode is used by Oracle Portal 3.0.
In this state, the mod_plsql calls htp.init after each request to only clear OWA packages, and not any application-specific variables and cursors. Furthermore, an implicit commit is done if there are no errors in processing the request.
PL/SQL applications are responsible for cleaning out the session at the end of request, but are not responsible for issuing commit in their code.
In this state, mod_plsql calls htp.init after each request to only clear out OWA packages, and not any application-specific variables and cursors. However, there is no implicit commit done at the end of the request.
PL/SQL applications are responsible for cleaning out the session at the end of request. They are also responsible for issuing commit in their code. They cannot assume that they start in a clean session. They start in whatever state the last session left off.
This mode is used in the embedded PL/SQL Gateway that ships with mod_ose. When using mod_ose, the stateful mode is preferable because a new database session does not have to be created and destroyed for every HTTP request. For more information, see the Oracle8i Oracle Servlet Engine User's Guide in the Oracle 9i Application Server Documentation Library.
Each PL/SQL Gateway request is associated with a Database Access Descriptor (DAD), a set of configuration values used for database access. A DAD specifies information such as:
You can also specify a username and password information in a DAD. If they are not specified, the user is prompted to enter a username and password when the URL is invoked. For more information, see "Authenticating Users".
To invoke the PL/SQL Gateway in a Web browser, input the URL in the following format:
protocol://hostname[:port]/prefix/DAD/[[!][schema.][package.]proc_ name[?query_string]]
| Parameter | Description |
|---|---|
|
protocol |
Either |
|
hostname |
The machine where the Web server is running. |
|
port |
The port at which the application server is listening. If omitted, port 80 is assumed. |
|
prefix |
A virtual path to handle PL/SQL requests that you have configured in the Web server. |
|
DAD |
The DAD entry to be used for this URL. |
|
! character |
Indicates to use the flexible parameter passing scheme. See"Flexible Parameter Passing" for more information. |
|
schema |
The database schema name. If omitted, name resolution for package.proc_name occurs based on the database user that the URL request is processed as. |
|
package |
The package that contains the PL/SQL stored procedure. If omitted, the procedure is stand-alone. |
|
proc_name |
The PL/SQL stored procedure to run. This must be a procedure and not a function. It can accept only IN arguments. |
|
(optional) |
The parameters for the stored procedure. The string follows the format of the GET method. For example:
|
Example 1: A Web server is configured with pls as a prefix and the browser sends the following URL:
http://www.acme.com:9000/pls/mydad/mypackage.myproc
The Web server running on www.acme.com and listening at port 9000 handles the request. When the Web server receives the request, it passes the request to the PL/SQL Gateway. This is because the pls prefix indicates that the Web server is configured to invoke the PL/SQL Gateway. The PL/SQL Gateway then uses the DAD associated with mydad and runs the myproc procedure stored in mypackage.
Example 2: Specify a URL without a DAD, schema, or stored procedure name.
http://www.acme.com:9000/pls/mydad
Then the default home page for the mydad DAD (as specified on the Gateway Configuration pages) displays.
Example 3: Specify a URL to invoke the default DAD's default home page:
http://www.acme.com:9000/pls
Generally, it does not matter what order the PL/SQL parameters are entered in the URL or the HTTP header since the parameters are passed by name. However, there are some exceptions to this rule. Refer to "Parameter passing" for more information.
The POST, GET and HEAD methods in the HTTP protocol instruct browsers on how to pass parameter data (usually in the form of name-value pairs) to applications. The parameter data is generated by HTML forms.
PL/SQL Gateway applications can use any of the methods. Each method is as secure as the underlying transport protocol (http or https).
After processing a URL request for a procedure invocation, the PL/SQL Gateway performs a rollback if there were any errors. Otherwise, the Gateway performs a commit. This mechanism does not allow a transaction to span across multiple HTTP requests. In this stateless model, applications typically maintain state using HTTP cookies or database tables. For more information about stateful and stateless modes, see "PL/SQL Gateway Configurations".
The PL/SQL Gateway supports:
Each parameter in a URL that invokes procedure or functions identified by a unique name. Overloaded parameters are supported. See "Parameter Passing by Name (Overloaded parameters)" for more information.
Procedures are prefixed by a ! character. See "Flexible Parameter Passing" for more information.
See "Large Parameter Passing" for more information.
Overloading allows multiple subprograms (procedures or functions) to have the same name, but differ in the number, order, or the datatype family of the parameters. When you call an overloaded subprogram, the PL/SQL compiler determines which subprogram to call based on the data types passed.
PL/SQL allows you to overload local or packaged subprograms. Stand-alone subprograms cannot be overloaded. See the PL/SQL User's Guide in the Oracle Server documentation for more information on PL/SQL overloading.
You must give parameters different names for overloaded subprograms that have the same number of parameters. Because HTML data is not associated with datatypes, the PL/SQL Gateway does not know which version of the subprogram to call.
For example, although PL/SQL allows you to define two procedures using the same parameter names for the procedures, an error occurs if you use this with the PL/SQL Gateway.
-- legal PL/SQL, but not for the PL/SQL Gateway
CREATE PACKAGE my_pkg AS
PROCEDURE my_proc (val IN VARCHAR2);
PROCEDURE my_proc (val IN NUMBER);
END my_pkg;
To avoid the error, name the parameters differently. For example:
-- legal PL/SQL and also works for the PL/SQL Gateway
CREATE PACKAGE my_pkg AS
PROCEDURE my_proc (valvc2 IN VARCHAR2);
PROCEDURE my_proc (valnum IN NUMBER);
END my_pkg;
The URL to invoke the first version of the procedure looks similar to:
http://www.acme.com/pls/myDAD/my_pkg.my_proc?valvc2=input
The URL to invoke the second version of the procedure looks similar to:
http://www.acme.com/pls/myDAD/my_pkg.my_proc?valnum=34
If you have overloaded PL/SQL procedures where the parameter names are identical, but the data type is owa_util.ident_arr (a table of varchar2) for one procedure and a scalar type for another procedure, the PL/SQL Gateway can still distinguish between the two procedures. For example, if you have the following procedures:
CREATE PACKAGE my_pkg AS
PROCEDURE my_proc (val IN VARCHAR2); -- scalar data type
PROCEDURE my_proc (val IN owa_util.ident_arr); -- array data type
END my_pkg;
Each of these procedures has a single parameter of the same name, val.
When the PL/SQL Gateway gets a request that has only one value for the val parameter, it invokes the procedure with the scalar data type.
Example 1: Send the following URL to execute the scalar version of the procedure:
http://www.acme.com/pls/myDAD/my_proc?val=john
When the PL/SQL Gateway gets a request with more than one value for the val parameter, it then invokes the procedure with the array data type.
Example 2: Send the following URL to execute the array version of the procedure:
http://www.acme.com/pls/myDAD/my_proc?val=john&val=sally
To ensure that the array version executes, use hidden form elements on your HTML page to send dummy values that are checked and discarded in your procedure.
The PL/SQL Gateway supports flexible parameter passing to handle HTML forms where users can select any number of elements. To use flexible parameter passing for a URL-based procedure invocation, prefix the procedure with an exclamation mark (!) in the URL. You can use two or four parameters. The two parameter interface provides improved performance with the PL/SQL Gateway. The four parameter interface is supported for compatibility.
|
Note: For questions about backwards compatibility with OAS, refer to "Using Flexible Parameters and the Exclamation Mark". |
procedure [proc_name] is
name_array IN [array_type],
value_array IN [array_type],
Table 1-3 Two Parameter Interface Parameters
Example: If you send the following URL:
http://www.acme.com/pls/myDAD/!scott.my_proc?x=john&y=10&z=doe
The exclamation mark prefix (!) instructs the PL/SQL Gateway to use flexible parameter passing. It invokes procedure scott.myproc and passes it the following two arguments:
name_array ==> (`x', `y', `z') values_array ==> ('john', '10', 'doe')
The four parameter interface is supported for compatibility. If you are experiencing overhead problems due to using the four parameter interface, refer to "The Flexible Parameter Passing (four parameter) Overhead".
procedure [proc_name] is (num_entires IN NUMBER, name_array IN [array_type], value_array IN [array_type], reserved in [array_type]);
Example: If you send the following URL, where the query_string has duplicate occurrences of the name "x":
http://www.acme.com/pls/myDAD/!scott.my_pkg.my_proc?x=a&y=b&x=c
The exclamation mark prefix (!) instructs the PL/SQL Gateway to use flexible parameter passing. It invokes procedure scott.my_pkg.myproc and passes it the following arguments:
num_entries ==> 3 name_array ==> (`x', `y', `x'); values_array ==> (`a', `b', `c') reserved ==> ()
The values passed as scalar arguments and the values passed as elements to the index-by table of varchar2 arguments can be up to 32K in size.
For example, when using flexible parameter passing (described in "Flexible Parameter Passing"), each name or value in the query_string portion of the URL gets passed as an element of the name_array or value_array argument to the procedure being invoked. These names or values can be up to 32KB in size.
The PL/SQL Gateway allows you to:
http://www.acme.com:9000/mysite/pls/docs/cs250/lecture1.htm
This is required to support uploading a set of files that have relative URL references to each other.
You can specify the document storage table on a per DAD basis. The document storage table must have the following definition:
CREATE TABLE [table_name] (
NAME VARCHAR2(256) UNIQUE NOT NULL, MIME_TYPE VARCHAR2(128), DOC_SIZE NUMBER, DAD_CHARSET VARCHAR2(128), LAST_UPDATED DATE, CONTENT_TYPE VARCHAR2(128), [content_column_name] [content_column_type] [ , [content_column_name] [content_column_type]]
);
Users can choose the table_name. The content_column_type type must be either LONG RAW or BLOB.
The content_column_name depends on the corresponding content_column_type:
An example of legal document table definition is:
NAME VARCHAR(128) UNIQUE NOT NULL, MIME_TYPE VARCHAR(128), DOC_SIZE NUMBER, DAD_CHARSET VARCHAR(128), LAST_UPDATED DATE, CONTENT_TYPE VARCHAR(128), CONTENT LONG RAW, BLOB_CONTENT BLOB ;
The contents of the table are stored in a content column. There can be more than one content column in a document table. However, for each row in the document table, only one of the content columns is used. The other content columns are set to NULL.
The content_type column tracks in which content column the document is stored. When a document is uploaded, the PL/SQL Gateway sets the value of this column to the type name.
For example, if a document was uploaded into the BLOB_CONTENT column, then the CONTENT_TYPE column for the document is set to the string `BLOB'.
The LAST_UPDATED column reflects a document's creation or last modified time. When a document is uploaded, the PL/SQL Gateway sets the
LAST_UPDATED column for the document to the database server time.
If an application then modifies the contents or attributes of the document, it must also update the LAST_UPDATED time.
The PL/SQL Gateway uses the LAST_UPDATED column to check and indicate to the HTTP client (browser) if the browser can use a previously cached version of the document. This reduces network traffic and improves server performance.
The DAD_CHARSET column keeps track of the character set setting at the time of the file upload. This column is reserved for future use.
For backward capability with the document model used by older releases of WebDB 2.x, the PL/SQL Gateway also supports the following old definition of the document storage table where the CONTENT_TYPE, DAD_CHARSET and LAST_UPDATED columns are not present.
/* older style document table definition (DEPRECATED) */ CREATE TABLE [table_name] (
NAME VARCHAR2(128), MIME_TYPE VARCHAR2(128), DOC_SIZE NUMBER, CONTENT LONG RAW
);
For each DAD, the following configuration parameters are relevant for file upload or download.
document_table (document_table_name)
The document_table parameter specifies the table to be used for storing documents when file uploads are performed via this DAD.
Syntax:
document_table = [document_table_name]
Examples:
document_table = my_documents
or,
document_table = scott.my_document_table
The document_path parameter specifies the path element to access a document. The document_path parameter follows the DAD name in the URL. For example, if the document access path is docs, then the URL would look similar to:
http://neon/pls/myDAD/docs/myfile.htm
The myDAD is the DAD name and myfile.htm is the file name.
Syntax:
document_path = [document_access_path_name]
The document_pro procedure is an application-specified procedure. It has no parameters and processes a URL request with the document access path. The document access procedure calls wpg_docload.download_file(filename) to download of a file. It knows the filename based on the URL specification. For example, this can be used by an application to implement file-level access controls and versioning. An example of such an application is shown in "File Download".
Syntax:
document_proc = [document_access_procedure_name]
Examples:
document_proc = my_access_procedure
or,
document_proc = scott.my_pkg.my_access_procedure
The DAD parameter, upload_as_long_raw, configures file uploads based on their file extensions. The value of an upload_as_long_raw DAD parameter is a comma separated (,) list of file extensions. Files with these extensions are uploaded by the PL/SQL Gateway into the content column of long_raw type in the document table. Files with other extensions are uploaded into the BLOB content column.
The file extensions can be text literals (jpeg, gif, etc.). In addition, an asterisk (*) can be used as a special file extension and matches any file whose extension has not been listed in an upload_as_long_raw setting.
Syntax:
upload_as_long_raw = [file_extension][,[file_extension]]*
[file_extension] is an extension for a file (with or without the `.' character, e.g., `txt' or `.txt') or the wildcard character *.
Examples:
upload_as_long_raw = html, txt upload_as_long_raw = *
To send files from a client machine to a database, create an HTML page that contains:
multipart/form-data and whose action attribute is associated with a PL/SQL Gateway procedure call, referred to as the "action procedure."
INPUT type="file" element enables a user to browse and select files from the file system.
When a user clicks Submit, the following events occur:
The following example shows an HTML form that lets a user select a file from the file system to upload. The form contains other fields that allow the user to provide information about the file.
<html> <head> <title>test upload</title> </head> <body> <FORM enctype="multipart/form-data" action="pls/myDAD/write_info" method="POST"> <p>Author's Name:<INPUT type="text" name="who"> <p>Description:<INPUT type="text" name="description"><br> <p>File to upload:<INPUT type="file" name="file"><br> <p><INPUT type="submit"> </FORM> </body> </html>
When a user clicks Submit on the form, the browser uploads the file listed in the INPUT type="file" element.
The write_info procedure then runs. The procedure writes information from the form fields to a table in the database and returns a page to the user. The action procedure does not have to return anything to the user, but it is a good idea to let the user know whether the Submit succeeded or failed.
A sample write_info procedure:
procedure write_info ( who in varchar2, description in varchar2, file in varchar2) as begin insert into myTable values (who, description, file); htp.htmlopen; htp.headopen; htp.title('File Uploaded'); htp.headclose; htp.bodyopen; htp.header(1, 'Upload Status'); htp.print('Uploaded ' || file || ' successfully'); htp.bodyclose; htp.htmlclose; end;
The filename obtained from the browser is prefixed with a generated directory name to reduce the possibility of name conflicts. The "action procedure" specified in the form renames this name. So, for example, when /private/minutes.txt is uploaded, the name stored in the table by the gateway is F9080/private/minutes.txt. The application can rename this in the called stored procedure. For example, the application can rename it to scott/minutes.txt.
When you upload HTML files, they are parsed by the PL/SQL Gateway for other parts (e.g. GIF/JPEG files). These parts details are maintained in a separate table called the documentparts table. The name of this table is based on your document table name. It must have the following signature:
create table %YOUR_DOCTABLE_NAME%part ( DOCUMENT VARCHAR2(256), PART VARCHAR2(256), UPLOADED CHAR(1), [add any more columns you want to add here] constraint %YOUR_DOCTABLE_NAME%part_pk primary key( document, part ) ) pctfree 0
Where %YOUR_DOCTABLE_NAME% is your document table name (see section Document Table Definition).
Appropriate privileges also must be granted to access this table:
grant select, insert, update on %YOUR_DOCTABLE_NAME%part to public
When the original HTML document is uploaded, examine the document parts table for any 'parts' that have not been uploaded. Use this information to notify the user. If the 'parts' are not uploaded in the document table, when a user downloads the HTML file, it does not display correctly (e.g. broken images).
In addition to renaming the uploaded file, the stored procedure can alter other file attributes. For example, the form in the example from "File Upload" could display a field for allowing the user to input the uploaded document's Multipurpose Internet Mail Extension (MIME) type.
The MIME type can be received as a parameter in write_info. The document table would then store the mime type for the document instead of the default mime type that is parsed from the multipart form by the PL/SQL Gateway when uploading the file.
To send multiple files in a single submit, the upload form must include multiple <INPUT type="file" name="file"> elements. If more than one file INPUT element defines name to be of the same name, then the action procedure must declare that parameter name to be of type owa.vc_arr. The names defined in the file INPUT elements could also be unique, in which case, the action procedure must declare each of them to be of varchar2. For example, if a form contained the following elements:
<INPUT type="file" name="textfiles"> <INPUT type="file" name="textfiles"> <INPUT type="file" name="binaryfile">
As a result, the action procedure must contain the following parameters:
procedure handle_text_and_binary_files(textfiles IN owa.vc_arr,
binaryfile IN varchar2).
After you have sent files to the database, you can download them, delete them from the database, and read and write their attributes.
To download a file, create a stored procedure without parameters that calls
wpg_docload.download_file (file_name) to initiate the download.
The HTML page presented to the user simply has a link to a URL which includes the Document Access Path and specifies the file to be downloaded.
For example, if the DAD specifies that the Document Access Path is docs and the Document Access Procedure is webview.process_download, then the webview.process_download procedure is called when the user clicks on the URL:
http://www.acme:9000/pls/webview/docs/myfile.htm
An example implementation of process_download is:
procedure process_download is v_filename varchar2(255); begin -- getfilepath() uses the SCRIPT_NAME and PATH_INFO cgi -- environment variables to construct the full pathname of
-- the file URL, and then returns the part of the pathname -- following `/docs/' v_filename := getfilepath; select name into v_filename from plsql_gateway_doc where UPPER(name) = UPPER(v_filename); -- now we call docload.download_file to initiate -- the download. wpg_docload.download_file(v_filename); exception when others then v_filename := null; end process_download;
Any time you call wpg_docload.download_file(filename) from a procedure running in the Gateway, a download of the file filename is initiated. However, when a file download is initiated, no other HTML (produced via HTP interfaces) generated by the procedure, is passed back to the browser.
The PL/SQL Gateway looks for the filename in the document table. There must be a unique row in the document table whose NAME column matches the filename. The PL/SQL Gateway generates HTTP response headers based on the information in the MIME_TYPE column of the document table. The content_type column's value determines which content columns the document's content comes from. The contents of the document are sent as the body of the HTTP response.
You can also download contents that are stored as a Binary Large Object (BLOB) data type.
Example: The following procedure uses the name from the argument to select a BLOB from a table and initiates the Direct BLOB download:
procedure download_blob(varchar2 name) is myblob blob; begin
select blob_data into myblob from mytable where blob_name = name;
owa_util.mime_header('text/html', FALSE); htp.p('Content-Length: ' || dbms_lob.get_length(myblob)); owa_util.http_header_close;
wpg_docload.download_file(myblob); end;
The structure of the mytable table:
create table mytable ( blob_name varchar2(128), blob_data blob );
Path Aliasing enables applications using the PL/SQL Gateway to provide direct reference to its objects using simple URLs. The PL/SQL Gateway allows you to directly access documents within an application using the document access path and a document access procedure. For example, the docs keyword in the URL below tells the PL/SQL Gateway that this request is for document access.
http://<HostName>[:Port]/<DADName>/docs/<FolderName/Document>
The above assumes that the Document Access Path is docs.
Path Aliasing provides the equivalent function by allowing means of direct access to application objects other than documents. Two fields in Database Access Descriptor's configuration information support path aliasing:
If the PL/SQL Gateway encounters in an incoming URL the keyword entered in the Path Alias field, it invokes the procedure entered in the Path Alias Procedure field.
For example, if the incoming URL is
http://www.acme.com:9000/portal_DAD/URL/path_alias_URL
and the Path Alias is URL, the PL/SQL Gateway invokes the Path Alias Procedure, passing everything after the keyword URL to the invoked procedure.
Applications that use path aliasing must implement the Path Alias Procedure. The procedure receives the rest of the URL (path_alias_URL) after the keyword, URL, as a single parameter, and is therefore responsible and also fully capable of dereferencing the object from the URL.
Although there is no restriction on the name and location for this procedure, it can accept only a single parameter, p_path, with the datatype varchar2.
The OWA_UTIL package provides an API to get the values of CGI environment variables, which serve to provide context to the procedure being executed via the PL/SQL Gateway. Although the PL/SQL Gateway is not operated through CGI, the PL/SQL application invoked from the PL/SQL Gateway can access these CGI environment variables. The following is a list of the available CGI Environment Variables:
| CGI Environment Variables | |
|---|---|
|
AUTHORIZATION |
DAD_NAME |
|
DOC_ACCESS_PATH |
DOCUMENT_TABLE (refer to "document_table (document_table_name)" |
|
HTTP_ACCEPT |
HTTP_ACCEPT_ENCODING |
|
HTTP_ACCEPT_CHARSET |
HTTP_ACCEPT_LANGUAGE |
|
HTTP_COOKIE |
HTTP_HOST |
|
HTTP_PRAGMA |
HTTP_REFERER |
|
HTTP_USER_AGENT |
PATH_ALIAS |
|
PATH_INFO |
REMOTE_ADDR |
|
REMOTE_HOST |
REMOTE_USER (refer to "REMOTE_USER CGI Environment Variable") |
|
REQUEST_CHARSET (refer to "REQUEST_CHARSET CGI environment variable") |
REQUEST_IANA_CHARSET |
|
REQUEST_METHOD |
REQUEST_PROTOCOL |
|
SCRIPT_NAME |
SCRIPT_PREFIX |
|
SERVER_NAME |
SERVER_PORT |
|
SERVER_PROTOCOL |
|
A PL/SQL application can get the value of a CGI environment variable using the owa_util.get_cgi_env interface.
Syntax:
owa_util.get_cgi_env(param_name in varchar2) return varchar2;
param_name is the name of the CGI environment variable. param_name is case-insensitive.
The cgi_env_list DAD parameter is a comma separated list of name and value pairs which can override any environment variables or add new ones. If the name is one of the original environment variables (as listed in "Common Gateway Interface (CGI) Environment Variables"), that environment variable is overridden with the given value. If the name is not in the original list, a new environment variable is added into the list with that same name and value given in the parameter.
If no value is specified for the parameter, then the value is obtained from the Oracle HTTP Server. With Apache, you can pass the DOCUMENT_ROOT CGI Environment variable by specifying:
cgi_env_list=DOCUMENT_ROOT
Access cgi_env_list through the PL/SQL Gateway configuration file (wdbsvr.app). This configuration file describes settings for the PL/SQL Gateway module. The location of your Oracle9i Application Server installation is <ORACLE_HOME>. For UNIX, the configuration file is located at:
<ORACLE_HOME>/Apache/modplsql/cfg/wdbsvr.app
For NT, it is located at:
<ORACLE_HOME>\Apache\modplsql\cfg\wdbsvr.app
Example 1:
cgi_env_list=SERVER_NAME=myhost.mycompany.com, REMOTE_USER=testuser
This example overrides the SERVER_NAME and the REMOTE_USER CGI environment variables with the given values since they are part of the original list.
Example 2:
cgi_env_list=MYENV_VAR=testing, SERVER_NAME=,REMOTE_USER=user2
This example overrides the SERVER_NAME and the REMOTE_USER variables. The SERVER_NAME variable is deleted since there is no value given to it. A new environment variable called MYENV_VAR is added since it is not part of the original list. It is assigned the value of "testing".
For PL/SQL Gateway mod_plsql, the National Language Support variable
(NLS_LANG) can be set either as an environment variable or at the DAD level. Refer to "DAD Settings Accessible through the Configuration File" for more information. The following restrictions apply:
Every request to the PL/SQL Gateway is associated with a DAD. The CGI environment variable REQUEST_CHARSET is set as follows:
The PL/SQL application can access this information via a function call of the form:
owa_util.get_cgi_env(`REQUEST_CHARSET');
This is the IANA (Internet Assigned Number Authority) equivalent of the
REQUEST_CHARSET CGI environment variable. IANA is an authority that globally coordinates the standards for charsets used on the Internet.
|
 Copyright © 2001 Oracle Corporation. All Rights Reserved. |
|