25 FTP, HTTP(S), and WebDAV Access to Repository Data

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 on 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.

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

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

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 this parameter. 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 to set_charset is not NULL, then <charset_name> is used to determine the character set of the data.

  If the parameter 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 mark^Foot 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 25-1 is an example of navigating the ASM virtual folder and listing the files in a subfolder.

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 25-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.

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

Using FTP on Standard or Nonstandard Ports

It can be configured through the Oracle XML DB configuration file /xdbconfig.xml, to listen on an arbitrary port. FTP ships listening on a nonstandard, unprotected port. To use FTP on the standard port (21), your DBA has to chown the TNS listener to setuid ROOT rather than setuid ORACLE.

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 the call-timeOut parameter in the Oracle XML DB configuration file. For high traffic sites, the 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.

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:

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.

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.

Using HTTP(S) on Nonstandard Ports

By default, HTTP listens on a nonstandard, unprotected port: 8080. To use HTTP(S) on the standard port, such as 80, your DBA must chown the TNS listener to setuid ROOT rather than setuid ORACLE, and configure the port number in the Oracle XML DB configuration file /xdbconfig.xml.

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.

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.

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.

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.

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.

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

Controlling Character Sets for HTTP(S)

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

WebDAV Features That Are Not Supported

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

• Lock-NULL resources create actual 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)