BUSINESS Version 25.10 os-OPNWAF: Nextcloud Proxy Pass Match

[Wuensch-AG-Adm]

Dear Community,
We would like to trigger the download via the share link in Nextcloud using OPNWAF's proxy feature.
I believe there is an option to use "Proxy Pass Match" for this.
But it doesn't seem to work and breaks the link. We know that the file downloads immediately if we append "/download" to the link without using the Nextcloud viewer.
We have tried the following:
      Local path
      ^/s/([^/]+)/?(.*)$
   
      Remote path
      /s/$1/download$2
This simply results in a 404 error and does not add the "/download" (the "$2" is because of the "dir" parameter that Nextcloud inserts into the email link).
We also tried the simplest method, but it doesn't work either. --> ^/s/?(.*)$ - /s/$1/download

Could you please give me some suggestions? (There isn't enough information in the online manual.)
Thank you ahead

Regards,

Joel

[Monviech (Cedrik)]

https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypassmatch

The documentation is unfortunately quite thin, and this is one of those areas where Apache's behavior is more limited than it initially appears.

While ProxyPassMatch inside a <LocationMatch> does reuse the regular expression, it is not a full rewrite engine. In particular, transforming URLs using captured groups in a reliable and flexible way is not really supported in this context.

What you're trying to achieve —modifying parts of a dynamic application URL (like Nextcloud share links)— is typically done using RewriteRule. However, introducing rewrite logic into OPNWAF is currently out of scope, as it significantly increases complexity and the likelihood of hard-to-debug configuration issues.

Because of that, we generally recommend not altering the URL structure of complex applications like Nextcloud at the proxy level. These applications often rely on very specific routing and parameters, and even small changes can easily break functionality (as you've already observed with the 404 errors).

If possible, the more robust approach is to work with the application's intended URLs (e.g. using /download directly where needed), rather than trying to enforce that behavior via the proxy layer.