Oracle UTL_HTTP(收集汇总实用资料)
From Oracle
The UTL_HTTP
package makes Hypertext Transfer Protocol (HTTP) callouts from SQL and PL/SQL. You
can use it to access data on the Internet over HTTP.
When the package fetches data from a Web site using HTTPS, it requires Oracle Wallet Manager which can be created by either Oracle Wallet Manager or the orapki utility. Non-HTTPS fetches do not require an Oracle wallet.
See Also:
-
Oracle Database Advanced Security Administrator's Guide for more information on Wallet Manager
This chapter contains the following topics:
-
-
Overview
-
Security Model
-
Constants
-
Datatypes
-
Operational Notes
-
Exceptions
-
Examples
-
-
-
Session Settings Subprograms
-
HTTP Requests Subprograms
-
HTTP Request Contexts Subprograms
-
HTTP Responses Subprograms
-
HTTP Cookies Subprograms
-
HTTP Persistent Connections Subprograms
-
Error Conditions Subprograms
-
Using UTL_HTTP
This section contains topics which relate to using the UTL_HTTP
package.
Overview
With the UTL_HTTP
package, you can write PL/SQL programs that communicate with Web (HTTP) servers. And UTL_HTTP
contains
a function that can be used in SQL queries.
The package supports HTTP over the Secured Socket Layer protocol (SSL), also known as HTTPS. It also supports SSL client authentication by sending the client-certificate in a wallet to authenticate with the remote Web server.
Other Internet-related data-access protocols (such as the File Transfer Protocol (FTP) or the Gopher protocol) are also supported using an HTTP proxy server that supports those protocols.
Security Model
This package is an invoker's rights package and the invoking user will need the connect
privilege granted in the access control list assigned to the remote network host to which he wants to connect,
as well as the use-client-certificates
or the use-passwords
privilege to authenticate himself with the remote Web server using the credentials stored in an Oracle wallet.
Note:
For more information, see Managing Fine-grained Access to External Network Services in Oracle Database Security GuideConstants
The UTL_HTTP
package uses the constants shown in following tables.
Table 225-1 UTL_HTTP Constants - HTTP Versions
Name | Type | Value | Description |
---|---|---|---|
|
|
|
Denotes HTTP version 1.0 that can be used in the function |
|
|
|
Denotes HTTP version 1.1 that can be used in the function |
Table 225-2 UTL_HTTP Constants - Default Ports
Name | Type | Value | Description |
---|---|---|---|
|
|
|
The default TCP/IP port (80) at which a Web server or proxy server listens |
|
|
|
The default TCP/IP port (443) at which an HTTPS Web server listens |
Table 225-3 UTL_HTTP Constants - HTTP 1.1 Status Codes
Name | Type | Value | Description |
---|---|---|---|
|
|
|
The client should continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. |
|
|
|
The server understands and is willing to comply with the client's request, through the Upgrade message header field, for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response. |
|
|
|
The request has succeeded. The information returned with the response is dependent on the method used in the request |
|
|
|
The request has been fulfilled and resulted in a new resource being created. |
|
|
|
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. |
|
|
|
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. |
|
|
|
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. |
|
|
|
The server has fulfilled the request and the user agent should reset the document view which caused the request to be sent. The response must not include an entity. |
|
|
|
The server has fulfilled the partial GET request for the resource. |
|
|
|
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location. |
|
|
|
The requested resource has been assigned a new permanent URI and any future references to this resource should use one of the returned URIs. |
|
|
|
The requested resource resides temporarily under a different URI. |
|
|
|
The response to the request can be found under a different URI and should be retrieved using a GET method on that resource. |
|
|
|
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server responds with this status code. |
|
|
|
The requested resource must be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. |
|
|
|
The requested resource resides temporarily under a different URI. |
|
|
|
The request could not be understood by the server due to malformed syntax. |
|
|
|
The request requires user authentication. The client may repeat the request with a suitable Authorization header field. If the |