Skip Headers
Oracle® XML DB Developer's Guide
11g Release 1 (11.1)

Part Number B28369-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

28 Using Protocols to Access the Repository

This chapter describes how to access Oracle XML DB Repository data using FTP, HTTP(S)/WebDAV protocols.

This chapter contains these topics:

Overview of Oracle XML DB Protocol Server

As described in Chapter 2, "Getting Started with Oracle XML DB" and Chapter 21, "Accessing Oracle XML DB Repository Data", Oracle XML DB Repository provides a hierarchical data repository in the database, designed for XML. Oracle XML DB Repository maps path names (or URLs) onto database objects of XMLType and provides management facilities for these objects.

Oracle XML DB also provides the Oracle XML DB protocol server. This supports standard Internet protocols, FTP, WebDAV, and HTTP(S), for accessing its hierarchical repository or file system. Note that HTTPS provides secure access to Oracle XML DB Repository.

These protocols can provide direct access to Oracle XML DB for many users without having to install additional software. The user names and passwords to be used with the protocols are the same as those for SQL*Plus. Enterprise users are also supported. DBAs can use these protocols and resource APIs such as DBMS_XDB to access Automatic Storage Management (ASM) files and folders in the repository virtual folder /sys/asm.

See Also:

Chapter 21, "Accessing Oracle XML DB Repository Data" for more information about accessing repository information, and restrictions on that access

Note:

  • When accessing virtual folder /sys/asm using Oracle XML DB protocols, you must log in as a DBA user other than SYS.

  • Oracle XML DB protocols are not supported on EBCDIC platforms.

Session Pooling

Oracle XML DB protocol server maintains a shared pool of sessions. Each protocol connection is associated with one session from this pool. After a connection is closed the session is put back into the shared pool and can be used to serve later connections.

Session pooling improves performance of HTTP(S) by avoiding the cost of re-creating session states, especially when using HTTP 1.0, which creates new connections for each request. For example, a couple of small files can be retrieved by an existing HTTP/1.1 connection in the time necessary to create a database session. You can tune the number of sessions in the pool by setting session-pool-size in Oracle XML DB xdbconfig.xml file, or disable it by setting pool size to zero.

Session pooling can affect users writing Java servlets, because other users can see session state initialized by another request for a different user. Hence, servlet writers should only use session memory, such as Java static variables, to hold data for the entire application rather than for a particular user. State for each user must be stored in the database or in a lookup table, rather than assuming that a session will only exist for a single user.

Figure 28-1 illustrates the Oracle XML DB protocol server components and how they are used to access files in Oracle XML DB Repository and other data. Only the relevant components of the repository are shown

Figure 28-1 Oracle XML DB Architecture: Protocol Server

Description of Figure 28-1 follows
Description of "Figure 28-1 Oracle XML DB Architecture: Protocol Server "

Oracle XML DB Protocol Server Configuration Management

Oracle XML DB protocol server uses configuration parameters stored in /xdbconfig.xml to initialize its startup state and manage session level configuration. The following section describes the protocol-specific configuration parameters that you can configure in the Oracle XML DB configuration file. The session pool size and timeout parameters cannot be changed dynamically, that is, you will need to restart the database in order for these changes to take effect.

Configuring Protocol Server Parameters

Figure 28-1 shows the parameters common to all protocols. All parameter names in this table, except those starting with /xdbconfig, are relative to the following XPath in the Oracle XML DB configuration schema:

/xdbconfig/sysconfig/protocolconfig/common

  • FTP-specific parametersTable 28-2 shows the FTP-specific parameters. These are relative to the following XPath in the Oracle XML DB configuration schema:

    /xdbconfig/sysconfig/protocolconfig/ftpconfig
    
    
  • HTTP(S)/WebDAV specific parameters, except servlet-related parametersTable 28-3 shows the HTTP(S)/WebDAV-specific parameters. These parameters are relative to the following XPath in the Oracle XML DB configuration schema:

    /xdbconfig/sysconfig/protocolconfig/httpconfig
    
    

Note:

You must either configure the port separately for each node of a Real Application Cluster (RAC) or configure it for one node and then restart the database instances on the other nodes. See "Configuring Oracle XML DB Using xdbconfig.xml".

See Also:

For examples of the usage of these parameters, see the configuration file, xdbconfig.xml.

Table 28-1 Common Protocol Configuration Parameters

Parameter Description

extension-mappings/mime-mappings

Specifies the mapping of file extensions to mime types. When a resource is stored in Oracle XML DB Repository, and its mime type is not specified, this list of mappings is used to set its mime type.

extension-mappings/lang-mappings

Specifies the mapping of file extensions to languages. When a resource is stored in Oracle XML DB Repository, and its language is not specified, this list of mappings is used to set its language.

extension-mappings/encoding-mappings

Specifies the mapping of file extensions to encodings. When a resource is stored in Oracle XML DB Repository, and its encoding is not specified, this list of mappings is used to set its encoding.

xml-extensions

Specifies the list of filename extensions that are treated as XML content by Oracle XML DB.

session-pool-size

Maximum number of sessions that are kept in the protocol server session pool

/xdbconfig/sysconfig/call-timeout

If a connection is idle for this time (in hundredths of a second), then the shared server serving the connection is freed up to serve other connections.

session-timeout

Time (in hundredths of a second) after which a session (and consequently the corresponding connection) will be terminated by the protocol server if the connection has been idle for that time. This parameter is used only if the specific protocol session timeout is not present in the configuration

schemaLocation-mappings

Specifies the default schema location for a given namespace. This is used if the instance XML document does not contain an explicit xsi:schemaLocation attribute.

/xdbconfig/sysconfig/default-lock-timeout

Time period after which a WebDAV lock on a resource becomes invalid. This could be overridden by a Timeout specified by the client that locks the resource.


Table 28-2 Configuration Parameters Specific to FTP

Parameter Description

buffer-size

Size of the buffer, in bytes, used to read data from the network during an FTP put operation. Set buffer-size to larger values for higher put performance. There is a trade-off between put performance and memory usage. Value can be from 1024 to 1048496, inclusive; the default value is 8192.

ftp-port

Port on which FTP server listens. By default, this is 0, which means that FTP is disabled. FTP is disabled by default because the FTP specification requires that passwords be transmitted in clear text, which can present a security hazard. To enable FTP, set this parameter to the FTP port to use, such as 2100.

ftp-protocol

Protocol over which the FTP server runs. By default, this is tcp.

ftp-welcome-message

A user-defined welcome message that is displayed whenever an FTP client connects to the server. If this parameter is empty or missing, then the following default welcome message is displayed: "Unauthorized use of this FTP server is prohibited and may be subject to civil and criminal prosecution."

session-timeout

Time (in hundredths of a second) after which an FTP connection will be terminated by the protocol server if the connection has been idle for that time.


Table 28-3 Configuration Parameters Specific to HTTP(S)/WebDAV (Except Servlet Parameters)

Parameter Description

http-port

Port on which the HTTP(S)/WebDAV server listens, using protocol http-protocol. By default, this is 0, which means that HTTP is disabled. If this parameter is empty (<http-port/>), then the default value of 0 applies. An empty parameter is not recommended.

This parameter must be present, whether or not it is empty; otherwise, validation of xdbconfig.xml against XML schema xdbconfig.xsd fails. The value must be different from the value of http2-port; otherwise, an error is raised.

http2-port

Port on which the HTTP(S)/WebDAV server listens, using protocol http2-protocol.

This parameter is optional, but, if present, then http2-protocol must also be present; otherwise, an error is raised. The value must be different from the value of http-port; otherwise, an error is raised. An empty parameter (<http2-port/>) also raises an error.

http-protocol

Protocol over which the HTTP(S)/WebDAV server runs on port http-port. Must be either TCP or TCPS.

This parameter must be present; otherwise, validation of xdbconfig.xml against XML schema xdbconfig.xsd fails. An empty parameter (<http-protocol/>) also raises an error.

http2-protocol

Protocol over which the HTTP(S)/WebDAV server runs on port http2-port. Must be either TCP or TCPS. If this parameter is empty (<http2-protocol/>), then the default value of TCP applies. (An empty parameter is not recommended.)

This parameter is optional, but, if present, then http2-port must also be present; otherwise, an error is raised.

session-timeout

Time (in hundredths of a second) after which an HTTP(S) session (and consequently the corresponding connection) will be terminated by the protocol server if the connection has been idle for that time.

max-header-size

Maximum size (in bytes) of an HTTP(S) header

max-request-body

Maximum size (in bytes) of an HTTP(S) request body

webappconfig/welcome-file-list

List of filenames that are considered welcome files. When an HTTP(S) get request for a container is received, the server first checks if there is a resource in the container with any of these names. If so, then the contents of that file are sent, instead of a list of resources in the container.

default-url-charset

The character set in which an HTTP(S) protocol server assumes incoming URL is encoded when it is not encoded in UTF-8 or the Content-Type field Charset parameter of the request.

allow-repository-anonymous-access

Indication of whether or not anonymous HTTP access to Oracle XML DB Repository data is allowed using an unlocked ANONYMOUS user account. The default value is false, meaning that unauthenticated access to repository data is blocked. See "Anonymous Access to Oracle XML DB Repository using HTTP".


Configuring Secure HTTP (HTTPS)

To enable Oracle XML DB Repository to use secure HTTP connections (HTTPS), a DBA must configure the database accordingly: configure parameters http2-port and http2-protocol, enable the HTTP Listener to use SSL, and enable launching of the TCPS Dispatcher. After doing this, the DBA must stop, then restart, the database and the listener.

See Also:

"Configuring Oracle XML DB Using xdbconfig.xml" for information about configuring Oracle XML DB parameters

Enable the HTTP Listener to Use SSL

A DBA must carry out the following steps, to configure the HTTP Listener for SSL.

  1. Create a wallet for the server and import a certificate – Use Oracle Wallet Manager to do the following:

    1. Create a wallet for the server.

    2. If a valid certificate with distinguished name (DN) of the server is not available, create a certificate request and submit it to a certificate authority. Obtain a valid certificate from the authority.

    3. Import a valid certificate with the distinguished name (DN) of the server into the server.

    4. Save the new wallet in obfuscated form, so that it can be opened without a password.

    See Also:

    Oracle Database Advanced Security Administrator's Guide for information about how to create a wallet
  2. Specify the wallet location to the server – Use Oracle Net Manager to do this. Ensure that the configuration is saved to disk. This step updates files sqlnet.ora and listener.ora.

  3. Disable client authentication at the server, since most Web clients do not have certificates. Use Oracle Net Manager to do this. This step updates file sqlnet.ora.

  4. Create a listening end point that uses TCP/IP with SSL – Use Oracle Net Manager to do this. This step updates file listener.ora.

See Also:

Oracle Database Advanced Security Administrator's Guide for detailed information regarding steps 1 through 4

Enable TCPS Dispatcher

A DBA must edit the database pfile to enable launching of a TCPS dispatcher during database startup. The following line must be added to the file, where SID is the SID of the database:

dispatchers=(protocol=tcps)(service=SIDxdb)

The database pfile location depends on your operating system, as follows:

  • MS Windows – PARENT/admin/orcl/pfile, where PARENT is the parent folder of folder ORACLE_HOME

  • Unix, Linux – $ORACLE_HOME/admin/$ORACLE_SID/pfile

Interaction with Oracle XML DB File-System Resources

The protocol specifications, RFC 959 (FTP), RFC 2616 (HTTP), and RFC 2518 (WebDAV) implicitly assume an abstract, hierarchical file system on the server side. This is mapped to Oracle XML DB Repository. The repository provides:

Protocol Server Handles XML Schema-Based or Non-Schema-Based XML Documents

Oracle XML DB protocol server enhances the protocols by always checking if XML documents being inserted are based on XML schemas registered in Oracle XML DB Repository.

  • If the incoming XML document specifies an XML schema, then the Oracle XML DB storage to use is determined by that XML schema. This functionality is especially useful when you must store XML documents object-relationally in the database using simple protocols like FTP or WebDAV instead of using SQL statements.

  • If the incoming XML document is not XML schema-based, then it is stored as a binary document.

Event-Based Logging

In certain cases, it may be useful to log the requests received and responses sent by a protocol server. This can be achieved by setting event number 31098 to level 2. To set this event, add the following line to your init.ora file and restart the database:

event="31098 trace name context forever, level 2"

Using FTP and Oracle XML DB Protocol Server

The following sections describe FTP features supported by Oracle XML DB.

Oracle XML DB Protocol Server: FTP Features

File Transfer Protocol (FTP) is one of the oldest and most popular protocols on the net. FTP is specified in RFC959 and provides access to heterogeneous file systems in a uniform manner. FTP works by providing well-defined commands (methods) for communication between the client and the server. The transfer of command messages and the return of status happens on a single connection. However, a new connection is opened between the client and the server for data transfer. With HTTP(S), commands and data are transferred using a single connection.

FTP is implemented by dedicated clients at the operating system level, file-system explorer clients, and browsers. FTP is typically session-oriented: a user session is created through an explicit logon, a number of files or directories are downloaded and browsed, and then the connection is closed.

Note:

For security reasons, FTP is disabled, by default. This is because the IETF FTP protocol specification requires that passwords be transmitted in clear text. Disabling is done by configuring the FTP server port as zero (0). To enable FTP, set the ftp-port parameter to the FTP port to use, such as 2100.

See Also:

FTP Features That Are Not Supported

Oracle XML DB implements FTP, as defined by RFC 959, with the exception of the following optional features:

  • Record-oriented files, for example, only the FILE structure of the STRU method is supported. This is the most widely used structure for transfer of files. It is also the default specified by the specification. Structure mount is not supported.

  • Append.

  • Allocate. This pre-allocates space before file transfer.

  • Account. This uses the insecure Telnet protocol.

  • Abort.

FTP Client Methods That Are Supported

For access to the repository, Oracle XML DB supports the following FTP client methods.

  • cdup – change working directory to parent directory

  • cwd – change working directory

  • dele – delete file (not directory)

  • list, nlst – list files in working directory

  • mkd – create directory

  • noop – do nothing (but timeout counter on connection is reset)

  • pasv, port – establish a TCP data connection

  • pwd – get working directory

  • quit – close connection and quit FTP session

  • retr – retrieve data using an established connection

  • rmd – remove directory

  • rnfr, rnto – rename file (two-step process: from file, to file)

  • stor – store data using an established connection

  • syst – get system version

  • type – change data type: ascii or image binary types only

  • user, pass – user login

See Also:

FTP Quote Methods

Oracle Database supports several FTP quote methods, which provide information directly to Oracle XML DB.

  • rm_r – Remove file or folder <resource_name>. If a folder, recursively remove all files and folders contained in <resource_name>.

    quote rm_r <resource_name>
    
    
  • rm_f – Forcibly remove a resource.

    quote rm_f <resource_name>
    
    
  • rm_rf – Combines rm_r and rm_f: Forcibly and recursively removes files and folders.

    quote rm_rf <resource_name>
    
    
  • set_nls_locale – Specify the character-set encoding (<charset_name>) to be used for file and directory names in FTP methods (including names in method responses).

    quote set_nls_locale {<charset_name> | NULL} 
    
    

    Only IANA character-set names can be specified for <charset_name>. If nls_locale is set to NULL or is not set, then the database character set is used.

  • set_charset – Specify the character set of the data to be sent to the server.

    quote set_charset  {<charset_name> | NULL}
    
    

    The set_charset method applies to only text files, not binary files, as determined by the file-extension mapping to MIME types that is defined in configuration file xdbconfig.xml.

    If the parameter provided to set_charset is <charset_name> (not NULL), then it specifies the character set of the data.

    If the parameter provided to set_charset is NULL, or if no set_charset command is given, then the MIME type of the data determines the character set for the data.

    • If the MIME type is not text/xml), then the data is not assumed to be XML. The database character set is used.

    • If the MIME type is text/xml, then the data represents an XML document.

      If a byte order markFoot 1  (BOM) is present in the XML document, then it determines the character set of the data.

      If there is no BOM, then:

      • If there is an encoding declaration in the XML document, then it determines the character set of the data.

      • If there is no encoding declaration, then the UTF-8 character set is used.

Using FTP with ASM Files

Automatic Storage Management (ASM) organizes database files into disk groups for simplified management and added benefits such as database mirroring and I/O balancing. DBAs can use protocols and resource APIs to access ASM files in the Oracle XML DB repository virtual folder /sys/asm. All files in /sys/asm are binary.

Typical uses are listing, copying, moving, creating, and deleting ASM files and folders. Example 28-1 is an example of navigating the ASM virtual folder and listing the files in a subfolder.

Example 28-1 Navigating ASM Folders

The structure of the ASM virtual folder, /sys/asm, is described in Chapter 21, "Accessing Oracle XML DB Repository Data". In this example, the disk groups are DATA and RECOVERY; the database name is MFG; and the directories created for aliases are dbs and tmp. This example navigates to a subfolder, lists its files, and copies a file to the local file system.

ftp> open myhost 7777
ftp> user system
ftp> passwd dba
ftp> cd /sys/asm
ftp> ls
DATA
RECOVERY
ftp> cd DATA
ftp> ls
dbs
MFG
ftp> cd dbs
ftp> ls
t_dbl.f
t_axl.f
ftp> binary
ftp> get t_dbl.f, t_axl.f
ftp> put my_db2.f

In this example, after connecting to and logging onto database myhost (first three lines), FTP methods cd and ls are used to navigate and list folders, respectively. When in folder /sys/asm/DATA/dbs, FTP command get is used to copy files t_db1.f and t_ax1.f to the current folder of the local file system. Then, FTP command put is used to copy file my_db2.f from the local file system to folder /sys/asm/DATA/dbs.

DBAs can copy ASM files from one database server to another, as well as between the database and a local file system. Example 28-2 shows copying between two databases. For this, the proxy FTP client method can be used, if available. The proxy method provides a direct connection to two different remote FTP servers.

Example 28-2 Transferring ASM Files Between Databases with FTP proxy Method

This example copies an ASM file from one database to another. Terms with suffix 1 correspond to database server1; terms with suffix 2 correspond to database server2.

1 ftp> open server1 port1
 2 ftp> user username1
 3 ftp> passwd password1
 4 ftp> cd /sys/asm/DATAFILE/MFG/DATAFILE
 5 ftp> proxy open server2 port2
 6 ftp> proxy user username2
 7 ftp> proxy passwd password2
 8 ftp> proxy cd /sys/asm/DATAFILE/MFG/DATAFILE
 9 ftp> proxy put dbs2.f tmp1.f
10 ftp> proxy get dbs1.f tmp2.f

In this example:

  • Line 1 opens an FTP control connection to the Oracle XML DB FTP server, server1.

  • Lines 2–3 log the DBA onto server1.

  • Line 4 navigates to /sys/asm/DATAFILE/MFG/DATAFILE on server1.

  • Line 5 opens an FTP control connection to the second database server, server2. At this point, the FTP command proxy ? could be issued to see the available FTP commands on the secondary connection. (This is not shown.)

  • Lines 6–7 log the DBA onto server2.

  • Line 8 navigates to /sys/asm/DATAFILE/MFG/DATAFILE on server2.

  • Line 9 copies ASM file dbs2.f from server2 to ASM file tmp1.f on server1.

  • Line 10 copies ASM file dbs1.f from server1 to ASM file tmp2.f on server2.

Using FTP on the Standard Port Instead of the Oracle XML DB Default Port

You can use the Oracle XML DB configuration file, /xdbconfig.xml, to configure FTP to listen on any port. By default, FTP listens on a nonstandard, unprotected port. To use FTP on the standard port, 21, your DBA must do the following:

  1. (UNIX only) Use this shell command to ensure that the owner and group of executable file tnslsnr are root:

    % chown root:root $ORACLE_HOME/bin/tnslsnr
    
    
  2. (UNIX only) Add the following entry to the listener file, LISTENER.ora, where hostname is your host name:

    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP) (HOST = hostname) (PORT = 21))
      (PROTOCOL_STACK = (PRESENTATION = FTP) (SESSION = RAW)))
    
    
  3. (UNIX only) Stop, then restart the listener, using the following shell commands, where user_id and group_id are your UNIX user and group identifiers, respectively:

    % lsnrctl stop
    % tnslsnr LISTENER -user user_id -group group_id &
    
    

    Use the ampersand (&), to execute the second command in the background. Do not use lsnrctl start to start the listener.

  4. Use PL/SQL procedure DBMS_XDB.setftpport with SYS as SYSDBA to set the FTP port number to 21 in the Oracle XML DB configuration file /xdbconfig.xml:

    SQL> exec DBMS_XDB.setFTPPort(21);
    
    
  5. Force the database to reregister with the listener, using this SQL statement:

    SQL> ALTER SYSTEM REGISTER;
    
    
  6. Check that the listener is correctly configured, using this shell command:

    % lsnrctl status
    

See Also:

FTP Server Session Management

Oracle XML DB protocol server also provides session management for this protocol. After a short wait for a new command, FTP returns to the protocol layer and the shared server is freed up to serve other connections. The duration of this short wait is configurable by changing parameter call-timeOut in the Oracle XML DB configuration file. For high traffic sites, call-timeout should be shorter, so that more connections can be served. When new data arrives on the connection, the FTP server is re-invoked with fresh data. So, the long running nature of FTP does not affect the number of connections which can be made to the protocol server.

See Also:

"Configuring Oracle XML DB Using xdbconfig.xml" for information about configuring Oracle XML DB parameters

Handling Error 421. Modifying the Default Timeout Value of an FTP Session

If you are frequently disconnected from the server and have to reconnect and traverse the entire directory before doing the next operation, you may need to modify the default timeout value for FTP sessions. If the session is idle for more than this period, it gets disconnected. You can increase the timeout value (default = 6000 centiseconds) by modifying the configuration document as follows and then restart the database:

Example 28-3 Modifying the Default Timeout Value of an FTP Session

DECLARE
  newconfig XMLType;
BEGIN
  SELECT 
    updateXML(
      DBMS_XDB.cfg_get(),
      '/xdbconfig/sysconfig/protocolconfig/ftpconfig/session-timeout/text()',
      123456789) 
    INTO newconfig 
    FROM DUAL;
  DBMS_XDB.cfg_update(newconfig);
END;/
COMMIT;

FTP Client Failure in Passive Mode

Do not use FTP in passive mode to connect remotely to a server that has HOSTNAME configured in Listener.ora as localhost or 127.0.0.1. If the HOSTNAME specified in server file Listener.ora is localhost or 127.0.0.1, then the server is configured for local use only. If you try to connect remotely to the server using FTP in passive mode, the FTP client will fail. This is because the server passes IP address 127.0.0.1 (derived from HOSTNAME) to the client, which makes the client try to connect to itself, not to the server.

Using HTTP(S) and Oracle XML DB Protocol Server

Oracle XML DB implements HyperText Transfer Protocol (HTTP), HTTP 1.1 as defined in the RFC2616 specification.

Oracle XML DB Protocol Server: HTTP(S) Features

The Oracle XML DB HTTP(S) component in the Oracle XML DB protocol server implements the RFC2616 specification with the exception of the following optional features:

  • gzip and compress transfer encodings

  • byte-range headers

  • The TRACE method (used for proxy error debugging)

  • Cache-control directives (these require you to specify expiration dates for content, and are not generally used)

  • TE, Trailer, Vary & Warning headers

  • Weak entity tags

  • Web common log format

  • Multi-homed Web server

    See Also:

    RFC 2616: HTTP 1.1 Protocol Specification—http://www.ietf.org/rfc/rfc2616.txt

HTTP(S) Features That Are Not Supported

Digest Authentication (RFC 2617) is not supported. Oracle XML DB supports Basic Authentication, where a client sends the user name and password in clear text in the Authorization header.

HTTP(S) Client Methods That Are Supported

For access to the repository, Oracle XML DB supports the following HTTP(S) client methods.

  • OPTIONS – get information about available communication options

  • GET – get document/data (including headers)

  • HEAD – get headers only, without document body

  • PUT – store data in resource

  • DELETE – delete resource

The semantics of these HTTP(S) methods are in accordance with WebDAV. Servlets and Web services may support additional HTTP(S) methods, such as POST.

See Also:

"Supported WebDAV Client Methods" for supported HTTP(S) client methods involving WebDAV

Using HTTP(S) on a Standard Port Instead of an Oracle XML DB Default Port

You can use the Oracle XML DB configuration file, /xdbconfig.xml, to configure HTTP(S) to listen on any port. By default, HTTP(S) listens on a nonstandard, unprotected port. To use HTTP or HTTPS on a standard port (80 for HTTP, 443 for HTTPS), your DBA must do the following:

  1. (UNIX only) Use this shell command to ensure that the owner and group of executable file tnslsnr are root:

    % chown root:root $ORACLE_HOME/bin/tnslsnr
    
    
  2. (UNIX only) Add the following entry to the listener file, LISTENER.ora, where hostname is your host name, and port_number is 80 for HTTP or 443 for HTTPS:

    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP) (HOST = hostname) (PORT = port_number))
      (PROTOCOL_STACK = (PRESENTATION = HTTP) (SESSION = RAW)))
    
    
  3. (UNIX only) Stop, then restart the listener, using the following shell commands, where user_id and group_id are your UNIX user and group identifiers, respectively:

    % lsnrctl stop
    % tnslsnr LISTENER -user user_id -group group_id &
    
    

    Use the ampersand (&), to execute the second command in the background. Do not use lsnrctl start to start the listener.

  4. Use PL/SQL procedure DBMS_XDB.sethtpport with SYS as SYSDBA to set the HTTP(S) port number to port_number in the Oracle XML DB configuration file /xdbconfig.xml, where port_number is 80 for HTTP or 443 for HTTPS:

    SQL> exec DBMS_XDB.setHTTPPort(port_number);
    
    
  5. Force the database to reregister with the listener, using this SQL statement:

    SQL> ALTER SYSTEM REGISTER;
    
    
  6. Check that the listener is correctly configured:

    % lsnrctl status
    

See Also:

HTTPS: Support for Secure HTTP

If properly configured, you can access Oracle XML DB Repository in a secure fashion, using HTTPS. See "Configuring Secure HTTP (HTTPS)" for configuration information.

Note:

If Oracle Database is installed on Microsoft Windows XP with Service Pack 2 (SP2), then you must use HTTPS for WebDAV access to Oracle XML DB Repository, or else you must make appropriate modifications to the Windows XP Registry. For information about the latter, see http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#XSLTsection129121120120

Anonymous Access to Oracle XML DB Repository using HTTP

Configuration parameter allow-repository-anonymous-access controls whether or not anonymous HTTP access to Oracle XML DB Repository data is allowed using an unlocked ANONYMOUS user account. The default value is false, meaning that unauthenticated access to repository data is blocked. To allow anonymous HTTP access to the repository, you must set this parameter to true, and unlock the ANONYMOUS user account.

Caution:

There is an inherent security risk associated with allowing anonymous access to the repository.

Parameter allow-repository-anonymous-access does not control anonymous access to the repository using servlets. Each servlet has its own security-role-ref parameter value to control its access.

See Also:

Using Java Servlets with HTTP(S)

Oracle XML DB supports Java servlets. To use a Java servlet, it must be registered with a unique name in the Oracle XML DB configuration file, along with parameters to customize its action. It should be compiled, and loaded into the database. Finally, the servlet name must be associated with a pattern, which can be an extension such as *.jsp or a path name such as /a/b/c or /sys/*, as described in Java servlet application program interface (API) version 2.2.

While processing an HTTP(S) request, the path name for the request is matched with the registered patterns. If there is a match, then the protocol server invokes the corresponding servlet with the appropriate initialization parameters. For Java servlets, the existing Java Virtual Machine (JVM) infrastructure is used. This starts the JVM if need be, which in turn runs a Java method to initialize the servlet, create response, and request objects, pass these on to the servlet, and run it.

Embedded PL/SQL Gateway

You can use the PL/SQL gateway to implement a Web application entirely in PL/SQL. There are two implementations of the PL/SQL gateway:

  • mod_plsql – a plug-in of Oracle HTTP Server that lets you invoke PL/SQL stored procedures using HTTP(S). Oracle HTTP Server is a component of both Oracle Application Server and Oracle Database; it should not be confused with the HTTP component of the Oracle XML DB protocol server.

  • the embedded PL/SQL gateway – a gateway implementation that runs in the Oracle XML DB HTTP listener.

With the PL/SQL gateway (either implementation), a Web browser sends an HTTP(S) request in the form of a URL that identifies a stored procedure and provides it with parameter values. The gateway translates the URL, calls the stored procedure with the parameter values, and returns output (typically HTML) to the Web-browser client.

Using the embedded PL/SQL gateway simplifies installation, configuration, and administration of PL/SQL based Web applications. The embedded gateway uses the Oracle XML DB protocol server, not Oracle HTTP Server. Its configuration is defined by the Oracle XML DB configuration file, /xdbconfig.xml. However, the recommended way to configure the embedded gateway is to use the procedures in PL/SQL package DBMS_EPG, not to edit file /xdbconfig.xml.

See Also:

Sending Multibyte Data From a Client

When a client sends multibyte data in a URL, RFC 2718 specifies that the client should send the URL using the %HH format, where HH is the hexadecimal notation of the byte value in UTF-8 encoding. The following are URL examples that can be sent to Oracle XML DB in an HTTP(S) or WebDAV context:

http://urltest/xyz%E3%81%82%E3%82%A2 
http://%E3%81%82%E3%82%A2 
http://%E3%81%82%E3%82%A2/abc%E3%81%86%E3%83%8F.xml

Oracle XML DB processes the requested URL, any URLs within an IF header, any URLs within the DESTINATION header, and any URLs in the REFERRED header that contains multibyte data.

The default-url-charset configuration parameter can be used to accept requests from some clients that use other, nonconforming, forms of URL, with characters that are not ASCII. If a request with such characters fails, try setting this value to the native character set of the client environment. The character set used in such URL fields must be specified with an IANA charset name.

default-url-charset controls the encoding for nonconforming URLs. It is not required to be set unless a nonconforming client that does not send the Content-Type charset is used.

See Also:

Characters That Are Not ASCII In URLs

Characters that are not ASCII that appear in URLs passed to an HTTP server should be converted to UTF-8 and escaped in the %HH format, where HH is the hexadecimal notation of the byte value. For flexibility, the Oracle XML DB protocol server interprets the incoming URLs by testing whether it is encoded in one of the following character sets in the order presented here:

  • UTF-8

  • Charset parameter of the Content-Type field of the request, if specified

  • Character set, if specified, in the default-url-charset configuration parameter

  • Character set of the database

See Also:

"Configuring Oracle XML DB Using xdbconfig.xml" for information about configuring Oracle XML DB parameters

Controlling Character Sets for HTTP(S)

The following sections describe how character sets are controlled for data transferred using HTTP(S).

Request Character Set

The character set of the HTTP(S) request body is determined with the following algorithm:

  • The Content-Type header is evaluated. If the Content-Type header specifies a charset value, the specified charset is used.

  • The MIME type of the document is evaluated as follows:

    • If the MIME type is "*/xml", the character set is determined as follows:

      - If a BOM is present, then UTF-16 is used.

      - If an encoding declaration is present, the specified encoding is used.

      - If neither a BOM nor an encoding declaration is present, UTF-8 is used.

    • If the MIME type is text, ISO8859-1 is used.

    • If the MIME type is neither "*/xml" nor text, the database character set is used.

There is a difference between HTTP(S) and SQL or FTP. For text documents, the default is ISO8859-1, as specified by the IETF.org RFC 2616: HTTP 1.1 Protocol Specification.

Response Character Set

The response generated by Oracle XML DB HTTP Server is in the character set specified in the Accept-Charset field of the request. Accept-Charset can have a list of character sets. Based on the q-value, Oracle XML DB chooses one that does not require conversion. This might not necessarily be the charset with the highest q-value. If Oracle XML DB cannot find one, then the conversion is based on the highest q-value.

Using WebDAV and Oracle XML DB

Web Distributed Authoring and Versioning (WebDAV) is an IETF standard protocol used to provide users with a file-system interface to Oracle XML Repository over the Internet. The most popular way of accessing a WebDAV server folder is through WebFolders on Microsoft Windows 2000 or Microsoft NT.

WebDAV is an extension to the HTTP 1.1 protocol that lets an HTTP server act as a file server. It lets clients perform remote Web content authoring through a coherent set of methods, headers, request body formats and response body formats. For example, a DAV-enabled editor can interact with an HTTP/WebDAV server as if it were a file system. WebDAV provides operations to store and retrieve resources, create and list contents of resource collections, lock resources for concurrent access in a coordinated manner, and to set and retrieve resource properties.

Oracle XML DB WebDAV Features

Oracle XML DB supports the following WebDAV features:

  • Foldering, specified by RFC2518

  • Access Control

WebDAV is a set of extensions to the HTTP(S) protocol that allow you to edit or manage your files on remote Web servers. WebDAV can also be used, for example, to:

WebDAV Features That Are Not Supported

Oracle XML DB supports the contents of RFC2518, with the following exceptions:

  • Lock-NULL resources create zero-length resources in the file system, and cannot be converted to folders.

  • The COPY, MOVE and DELETE methods comply with section 2 of the Internet Draft titled 'Binding Extensions to WebDAV'.

  • Depth-infinity locks

  • Only Basic Authentication is supported.

Supported WebDAV Client Methods

For access to the repository, Oracle XML DB supports the following HTTP(S)/WebDAV client methods.

  • PROPFIND (WebDAV-specific) – get properties for a resource

  • PROPPATCH (WebDAV-specific) – set or remove resource properties

  • LOCK (WebDAV-specific) – lock a resource (create or refresh a lock)

  • UNLOCK (WebDAV-specific) – unlock a resource (remove a lock)

  • COPY (WebDAV-specific) – copy a resource

  • MOVE (WebDAV-specific) – move a resource

  • MKCOL (WebDAV-specific) – create a folder resource (collection)

See Also:

Using WebDAV with Microsoft Windows XP SP2

If Oracle Database is installed on Microsoft Windows XP with Service Pack 2 (SP2), then you must use a secure connection (HTTPS) for WebDAV access to Oracle XML DB Repository, or else you must make appropriate modifications to the Windows XP Registry.

See Also:

Using Oracle XML DB and WebDAV: Creating a WebFolder in Windows 2000

To create a WebFolder in Windows 2000, follow these steps:

  1. From your desktop, select My Network Places.

  2. Double-click Add Network Place.

  3. Type the location of the folder, for example:

    http://Oracle_server_name:HTTP_port_number
    
    

    See Figure 28-2.

  4. Click Next.

  5. Enter any name to identify this WebFolder

  6. Click Finish.

You can now access Oracle XML DB Repository just like you access any Windows folder.

Figure 28-2 Creating a WebFolder in Windows 2000

Description of Figure 28-2 follows
Description of "Figure 28-2 Creating a WebFolder in Windows 2000"



Footnote Legend

Footnote 1: BOM is a Unicode-standard signature that indicates the order of the stream of bytes that follows it.