[BUG] File with external link cannot be found using the "/attachment" endpoint

[TomGneuss]

Describe the bug
A SME of subtype "File" can specify the path to a file as link to an external file on the internet in the value field. These files can be downloaded - just like files with local paths - using the /submodels/{sm-id}/submodel-elements/{id-short-path}/attachment endpoint.

The implementation tries to find the file locally - even if the path in the value field starts with https://.
In the org.eclipse.digitaltwin.basyx.core.filerepository.MongoDBFileRepository class (particulary in the find() method, there is no means of checking whether the file could be located externally.

Thus, the download failed with the message

404ErrorFileDoesNotExistException-404Requested File inside the Asset administration shell or File SubmodelElement with ID : File at path 'https://<my-web-path>' could not be found. does not exist2025-09-03T13:45:01.654953586Z

To Reproduce
Steps to reproduce the behavior:

1. Start the AAS-Environment application
2. Upload an AAS with a SM containing at least one "File"-type SME
3. Make sure the value in the "File"-type SME points to some remote file
4. Try downloading the file using the GetFileByPath endpoint

Expected behavior
The file is provided - either from the backend of the application or because the application itself sets out to download/cache the remote file before delivering it.

BaSyx (please complete the following information):

• BaSyx Version: docker.io/eclipsebasyx/aas-environment:2.0.0-SNAPSHOT
• BaSyx SDK; Java
• AAS Version: DotAAS V3

BaSyx configuration

System (please complete the following information):

• OS: Linux
• CPU architecture: x86
• Browser: Chrome

[aaronzi]

Hi @TomGneuss,

maybe I have a misunderstanding here but isn't the /attachment endpoint only used for files that are actually part of an AAS? The rest should be handled on the clients end. That's at least how I have seen it in other implementations and in our client and UI implementations as well.

[TomGneuss]

That is definitely a valid standpoint that I can understand. However, that does make the client implementation more complex. IMO, the client should not be responsible for checking the value field first to determine how to obtain the file. I would expect this to be transparently handled by the server using the /attachment endpoint.

I would prefer if there was some official statement, since I cannot seem to find any clarification in the specification - only hints for interpretation in the context of AASX packages.

[aaronzi]

Please ask your question here then: https://github.com/admin-shell-io/aas-specs-api

Our clients are doing this check based on the value of the file SME.