HTTP-Data-Plane-Extension: make the proxypath decoding configurable

[oliverbusch]

Feature Request

When connecting to a backend service, there is a problem if the ProxyPath is not to be encoded.

Here is an example:

The connected backend service requires the following parameter to provide the data:

smart.data%2Fdemo%2Frepo%2F1%2F1%2F454576463545648365874

The transfer is done with the following command

curl --location --request GET 'http://localhost:19191/api/public/1/smart.data%2Fdemo%2Frepo%2F1%2F1%2F454576463545648365874' \
--header 'Authorization: 1234' \
--header 'X-Api key: password'

In the DataPlane log console, you can see that the URL is encoded

DEBUG 2024-02-13T12:34:06.879157137 Executing HTTP request: https://backend/repository/smart.data/demo/repo/1/1/454576463545648365874

But the backend expects the following url
https://backend/repository/smart.data%2Fdemo%2Frepo%2F1%2F1%2F454576463545648365874

For this use case it should be possible to make the decoding configurable

Which Areas Would Be Affected?

data-plane-http

Why Is the Feature Desired?

Enhanced compatibility with back-end systems

Solution Proposal

Change/extend the implementation in

Connector/extensions/data-plane/data-plane-http/src/main/java/org/eclipse/edc/connector/dataplane/http/params/HttpRequestFactory.java

Line 102 in 1324429

builder.addPathSegments(sanitizedPath);

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[jimmarino]

I don't necessarily think we should do this. If paths need to be manipulated, this should be done explicitly via a gateway/proxy implementation. For example see the Tractus-X ProviderGatewayController,

[oliverbusch]

I understand your reasoning. But you also have to consider that the barrier to entry for "basic" users is unnecessarily high. You can't just create a proxy service using the "standard" connector.

[jimmarino]

I understand your reasoning. But you also have to consider that the barrier to entry for "basic" users is unnecessarily high. You can't just create a proxy service using the "standard" connector.

Having an implicit mapping like that is not good practice (it couples internal path details with an external URL) and is a potential security hole. Implicit mappings are generally good for tutorial-style use cases, not production scenarios.

[oliverbusch]

I completely agree with your statements. Allowing special characters in entity IDs (coupling internal path information with an external URL) is not good practice, but is allowed by some backends.

However, in my opinion it is essential for the acceptance of the EDC that it also supports the simplest scenarios without much effort. I.e. calls like

https://backend/repository/smart.data/demo/repo/1/1/454576463545648365874
https://jsonplaceholder.typicode.com/comments?postId=2

should be supported out of the box.

But neither of them currently works out of the box, making it difficult to get started.
In the end, it is a compromise between "good design" and "usability". And in this case, the decision was made in favor of "good/safe design".

[oliverbusch]

@jimmarino
The ProviderGatewayController listed above no longer seems to exist. What other options are there in this regard? The endpointUrl from DataPlane Proxy Consumer API no longer works either.

[jimmarino]

@jimmarino The ProviderGatewayController listed above no longer seems to exist. What other options are there in this regard? The endpointUrl from DataPlane Proxy Consumer API no longer works either.

Please see this Decision Record. A proxy can be created by writing a JAX-RS controller.