Skip to Main Content
Feature Request FR-4347
Product Area Web Services
Status CLOSED

1 Voters

Change Request: apex_web_service should use utl_http.create_request_context

rode.mb Public · Mar 21 2025

Idea Summary
apex_web_service.make_rest_request should use create_request_context instead of set_wallet.

This won't have changes for the user but it can prevent possible (rare and random) bugs at runtime.

Use Case
You can reproduce this bugs on a later 19c release. Since (about) 19.19 there is a (inofficial) backport for “wallet_path=system:” - actually this works fine. but you have to use request context or you will run into random ORA-29248 exceptions.

create a scheduler job that calls a url every minute and check the user_scheduler_job_run_details later…:

DECLARE
  x CLOB;
BEGIN
  x := apex_web_service.make_rest_request(p_url         => 'https://oracle.com',
                                          p_http_method => 'GET',
                                          p_wallet_path => 'system:');
END;

It seems to be some issue of utl_http, because in 23ai the issue is not reproducable, but using request context would not hurt at all.

Preferred Solution (Optional)
Some small modifications in WWV_FLOW_WEB_SERVICES_INVOKER should be enough.

We reviewed this idea carefully, and while it was interesting, we concluded that due to all the internal implications we need to take into account, it is unlikely to make its way into APEX.

Comments

Comments

  • carsten.czarski APEX Team OP 1.4 years ago

    I just had a look into the documentation for UTL_HTTP.SET_WALLET (19c | 23ai). On 19c, the system: prefix is not mentioned at all. So, even if that technically works, there might be other caveats as well - probably the reason why this is not documented. 

    So all in all I would not recommend to use this on 19c at all. Instead - as we always did: place the wallet on a folder in the operating system, and use the wallet path with APEX_WEB_SERVICE or configure in the INTERNAL workspace. On 23ai databases, nothing stops you from using the system: prefix.

    Even though the create_request_context procedure might help in that case - at the end it's working around issues you're getting by using undocumented functionality in 19c databases. To be honest, I'm struggling to see the need for changing the APEX_WEB_SERVICE infrastructure with all required testing overhead and risk involved for that purpose ...

  • weberge42 OP 5 days ago

    @carsten.czarski system: is availble since 19.16 and is mentioned in the 19c docs, e.g. “Table 273-58 SET_WALLET Procedure Parameters”

    so there is no reason to not use this. i opened SR 4-0003427811 and SPIN-OFF SR 4-0003377347 because of this problem. create_request_context works for utl_http but not for apex_web_services.

  • weberge42 OP 5 days ago

    opened FR-4979 sind his one is closed

  • carsten.czarski APEX Team OP 5 days ago

    Which concrete 19c Release are you using? I remember talking to a customer who told me that they did not see issues with a later 19c patch level.

  • rode.mb OP 5 days ago

    @carsten.czarski 

    Hi Carsten,

    I last tested it with version 19.30, and I'm sure it's still an issue in 19.32.

    The real problem is that `set_wallet` doesn't work reliably in 19c, and `apex_web_service` relies on `set_wallet` instead of `request_context`.

    This feature has been included for years (since 19.16), has been actively promoted by Connor McDonald in talks since around 19.20 (disclaimer: “undocumented”), even with “apex_web_service,” and has been included in the documentation since 19.24. Since then, I’ve opened tickets with both the Apex and DB teams, and they’ve been passing the buck back and forth.

    Surely it must be possible for someone at Oracle to step up and fix this problem.

    The bug can be easily reproduced in any environment with a two-liner for a scheduler job. As mentioned earlier, the error occurs only occasionally, so you may have to wait a few minutes before you see that the problem apparently hasn’t been fixed yet.

    Thanks,

    Roland

  • carsten.czarski APEX Team OP 5 days ago

    The real problem is that `set_wallet` doesn't work reliably in 19c, and `apex_web_service` relies on `set_wallet` instead of `request_context`.

    Oh, SET_WALLET works reliably with a database wallet. SET_WALLET using system: is the thing which has issues.

    I totally agree that this should be fixed, but as stated above: With all the implications this has for APEX_WEB_SERVICE, its underlying infrastructure and the risk for existing apps, I don't think we can prioritize a project in APEX which actually works around this SET_WALLET issue, and only on 19c, and only when using SYSTEM: wallet.

  • weberge42 OP 4 days ago

    @carsten.czarski both of them work reliably - but not consecutively in the same database session.

    Does not matter if you start with system: and then wallet path or the other way round.

  • carsten.czarski APEX Team OP 4 days ago

    So, SET_WALLET is used in APEX since APEX_WEB_SERVICE package exists in APEX 3.0. I never heard about issues with using SET_WALLET and then a file:/// URL to reference a wallet folder.  That's used by thousands of customers without issues across the planet.

    I have seen issues with the system: string, but those were specific to use system:

  • carsten.czarski APEX Team OP 4 days ago

    However, I think the ideas app is the wrong forum for such a discussion. Such discussion should IMO happen on the APEX forum:

    https://forums.oracle.com/ords/apexds/domain/dev-community/category/apex

  • rode.mb OP 4 days ago

    No problem - I've since built a better `make_rest_request` wrapper for 19c. I didn't really want to reopen the discussion either; I just felt prompted to respond by the new comment.

    I can totally understand why this sensitive part of the code isn't being touched anymore. There are certainly more important issues to address.

    Thanks,

    Roland

  • weberge42 OP 4 days ago

    @carsten.czarski 

    “about issues with using SET_WALLET and then a file:///” and this is not the problem either. its the combination of both methods consecutively in the same database session. Both of them work without any problem when used alone.

    this is definitely an rdbms bug/proble - but yes, SR and the forum are better places for this :)