Search Results http_cookie2array




Overview
Explore in AI Chat

Overview

OWAPUB.OWA_COOKIE is a server-side PL/SQL package that implements HTTP cookie handling within the Oracle E-Business Suite web tier. It belongs to the OWAPUB library, the set of Oracle Web Agent (OWA) packages that predate and underpin the mod_plsql / Oracle HTTP Server integration used by EBS 12.1.1 and 12.2.2. The package provides the mechanics for reading cookies supplied by the browser on an inbound request and for emitting Set-Cookie directives on an outbound response. Because EBS pages are generated dynamically through the Apache/PLSQL gateway rather than by static scripts, cookie persistence for session affinities, user preferences, and self-service personalization must be handled programmatically. OWA_COOKIE supplies that capability.

The documented type metadata classifies the package under owner SYS with an API classification of OTHER, and it is referenced by one other package in the ETRM inventory. Its procedures are consumed indirectly by the framework rather than called directly from end-user forms, which is typical of the OWAPUB layer.

Key Procedures and Functions

The ETRM metadata documents five entry points: INIT, SEND, GET, REMOVE, and GET_ALL.

  • INIT — Initializes the package's internal state, resetting the cached cookie arrays and parse flag so that a subsequent read reflects the current request.
  • SEND — Writes a cookie back to the client by constructing the appropriate response header, optionally including an expiry date (converted to GMT), path, domain, and secure flag.
  • GET — Retrieves the value of a single named cookie from the current request, returning NULL when the cookie is absent.
  • REMOVE — Expires or deletes a named cookie on the client, typically by reissuing it with a past expiration date.
  • GET_ALL — Returns the complete set of cookies present on the request in a structured form suitable for iteration by calling code.

The body source excerpt supplied with the search term "http_cookie2array" reveals the internal parsing routine that these public procedures depend upon. http_cookie2array reads the CGi environment variable HTTP_COOKIE through owa_util.get_cgi_env, trims a trailing semicolon, and then walks the string using INSTR to locate each ';' delimiter and each '=' separator. Cookie names are captured with LTRIM to strip leading whitespace, values are extracted between the equals sign and the delimiter, and a counter (num_vals) records how many cookies were parsed. A final cookie without a trailing delimiter is handled after the loop. This routine is what backs GET and GET_ALL; INIT clears the cookies_parsed flag so that the array is rebuilt on the next call.

Tables Accessed

The ETRM metadata records no tables referenced through APPS synonyms for this package. This is consistent with its design: OWA_COOKIE is stateless with respect to the database and operates entirely on the HTTP cookie string carried in the CGI environment and on the response headers it generates. Its only persistence layer is the client browser, not the EBS schema. The package-level variables cookie_names, cookie_vals, cookie_num_vals, and cookies_parsed are session-scoped PL/SQL constructs, not database objects.

Usage Notes

OWA_COOKIE is invoked from server-side PL/SQL that executes inside the EBS web tier, most commonly from custom JSP/PLSQL regions, Oracle Application Framework pages that fall back to the OWA layer, or custom concurrent-request-driven HTML generation. Developers should call INIT or GET before relying on cached values so that the current request's cookie string is parsed. Because SEND writes HTTP headers, it must execute before any page output is flushed; calling it after content has been emitted will fail. In EBS 12.2.2 the runtime stack moved to WebLogic, and reliance on OWAPUB packages generally decreases in favor of the newer framework, but legacy forms and customizations that still route through mod_plsql continue to depend on OWA_COOKIE. Custom code should treat the documented procedures as the supported interface and avoid referencing the private parsing routine or package globals directly, as these are not part of the published contract and may change between patch levels.