Skip to Main Content

ORDS, SODA & JSON in the Database

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Enabling compression in ORDS on Tomcat

S-MaxFeb 10 2025 — edited Feb 10 2025

Hi all,

with Rest Data Sources in APEX I get the data as JSON from the provider. For about one week the provider has activated the compression for all API calls. Now I have to ensure that compression support is enabled in my calls and make sure the “Accept-Encoding” header is included in the request and specifies “gzip”, for example, “Accept-Encoding: gzip”.

After the compression activation I have the problems with the encoding of the german umlauts. For exmaple for “Baden-Württemberg” I get now “Baden-Württemberg”.

After the activating the compression I can get the data with curl only with “--compression” key. With postman I have no problems.

In order to activate the compression for ORDS (Version: 21.1.3.r1531102) on Tomcat 9.0.46 I have edited the server.xml file of Tomcat and added “compression”, “CompressionMinSize” and “compressionMimeType” to the connector:

<Connector port="8080" 
               protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443"
               compression="on"
               compressionMinSize="128"
               compressibleMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml" />

After Tomcat restart I have tested the results of the Rest Data Sources in APEX and the unlauts are still not decoded.

Dear friends, what am I doing wrong?

Thank you!

This post has been answered by S-Max on Feb 19 2025
Jump to Answer

Comments

thatJeffSmith-Oracle Feb 13 2025

Your ENTRA users will get authenticated via JSON Web Tokens, and their Entra roles will determine which ORDS REST APIs they can hit.

When they hit an endpoint, it'll execute code in the database as the database user that owns the schema where the REST API is defined, not as Entra defiend end user. In fact, the Entra users won't have accounts in the database (they could, but wont' need to).

The :current_user field as far as ords is concerned would be the corresponding oauth2 client or JWT issued for the authorizied session.

Your prehook should be able to alter the session to set the context that would put your RLS/VPD security policy in play.

1 - 1

Post Details

Added on Feb 10 2025
4 comments
104 views