Binary field viewFile/downloadFile URL generation broken after upgrading from SmartClient 12.1 to 14.1

[senordhuff]

Hi SmartClient team,

I'm experiencing an issue with binary field URL generation after upgrading from
SmartClient 12.1 to 14.1. The viewFile and downloadFile operations are generating
malformed URLs that don't work correctly.

Environment:
- SmartClient version: 14.1p_2025-07-26 (upgraded from 12.1)
- Server: Java with SmartClient Server Framework
- Application context path: /dev/

Problem Description:

In SmartClient 12.1, binary fields with type="binary" in ListGrids correctly generated
URLs like:
/dev/smartclient.form?isc_rpc=1&_transaction=<encoded-request>

After upgrading to SmartClient 14.1, the same binary fields now generate malformed URLs
like:
smartclient.form/filename.pdf?isc_rpc=1&_transaction=<encoded-request>

Issues:
1. Missing application context path (/dev/)
2. Filename incorrectly appended as path segment instead of using query parameters
3. Results in 404 errors since the URL doesn't resolve correctly

DataSource Configuration:
<DataSource ID="DepartmentFile" dataURL="smartclient.form">
<fields>
<field name="attachedFile" type="binary">
<title>Attached File</title>
</field>
<field name="attachedFile_filename" type="text">
<title>File Name</title>
</field>
</fields>
</DataSource>

Current Workaround:
I've implemented a temporary client-side fix that intercepts the generated HTML and
corrects the URLs:

isc.ListGrid.addProperties({
dataChanged: function() {
this.Super("dataChanged", arguments);
var self = this;
setTimeout(function() {
var gridElement = self.getHandle();
if (gridElement) {
var brokenLinks =
gridElement.querySelectorAll('img[onclick*="smartclient.form/"]');
for (var i = 0; i < brokenLinks.length; i++) {
var onclick = brokenLinks[i].getAttribute('onclick');
if (onclick) {
onclick = onclick.replace(/smartclient\.form\/[^?&]+(\?)/g,
'/dev/smartclient.form$1');
brokenLinks[i].setAttribute('onclick', onclick);
}
}
}
}, 100);
}
});

Questions:
1. Was this a deliberate change in SmartClient 14.1's binary field URL generation?
2. Is there a proper configuration setting to fix this without client-side workarounds?
3. Should the dataURL in datasource definitions now include the full context path?

Additional Context:
- Normal fetch/add/update operations work correctly with the same
dataURL="smartclient.form"
- Only viewFile/downloadFile operations are affected
- URL resolution methods like isc.Page.getURL("smartclient.form") return the relative
path without context resolution

Any guidance on the correct way to handle this in SmartClient 14.1 would be greatly
appreciated.

Thanks!

[Isomorphic]

Adding the filename is an intentional change because we found that it is the only way for some browsers (and servers) to get the mime-type right.

There was a corresponding change, in web.xml, to map the default IDACall servlet so that it handles all downstream paths (/*) instead of just a single path.

It sounds like you placed IDACall at a custom URL (smartclient.form) so you just need to make sure your custom mapping is changed in the same way we changed the default mapping.

Note you may also have some client-side changes (maybe setting the default RPCManager.actionURL?) that may also need to be synced up.

[senordhuff]

Thanks for the clarification! I found my mapping is done via Spring configuration:

@Bean(name = "/smartclient.form")

Should I change this to?
@Bean(name = "/smartclient.form/*")

Also, do I need to set RPCManager.actionURL on the client side? If so, what should it be set to based on the Datasource definition for DepartmentFile I shared?

[Isomorphic]

No, the "name" of a bean in Spring isn't a URL. You want @RequestMapping - here's a quick AI-generated sample:

https://chatgpt.com/share/68ab777c-8...f-3248b1ac73d2

And to clarify - you normally would not need to do anything, even on an upgrade, because this works out of the box if you follow the standard install.

You just have to adjust your customizations, and we don't really know enough about those to give advice.

For example, the normal approach is that if you have .ds.xml files, and they use the built-in protocol to contact the server, then there would be no reason to set dataURL in each file, because they just use the centrally defined RPCManager.actionURL by default, and that's what you want.

So, unless you remember a specific reason for doing this, what you might want to do is just delete everywhere that you customized the URLs for contacting the SmartClient Server, since then you'll be all set.

[senordhuff]

The fix was exactly what you suggested. I found my Spring configuration was using SimpleUrlHandlerMapping with:

urlProperties.put("/smartclient.form", smartClientController());

I changed it to:

urlProperties.put("/smartclient.form/*", smartClientController());

Result: Binary field viewFile/downloadFile operations now work perfectly with SmartClient 14.1. The URLs are correctly generated as /dev/smartclient.form/filename.pdf and my controller properly handles the wildcard path.

Thank you!