Hey @Jianchi-Chen, thanks for the MR! I would prefer if this fixes the problem at the source rather than trying to fix the wrongly generated URL after the fact. Since the UI already knows when it's getting a prefix, how about you try to make it generate the correct links instead?

Hi @svenstaro, thanks for the feedback!

I understand your point about fixing the issue at the source — in this case, the UI.
After updating the frontend generation logic, the delete button in the WebUI now works correctly, since the generated URL no longer duplicates the prefix.

However, when testing manually via curl, for example:
curl -X POST http://127.0.0.1:9999/prefix/rm?path=/prefix/testfile
still results in a 400 error, while
curl -X POST http://127.0.0.1:9999/prefix/rm?path=/testfile
works as expected.

So it seems the UI fix resolves the issue for normal users, but direct API calls (that include the prefix in the path) still fail.
Would you prefer we leave it as-is , or also handle such cases in the backend for consistency?

Right, but how would users arrive at an incorrect curl command in the first place? I mean, I think people would handwrite the curl command so there should not be anything to fix here, I reckon.

@Jianchi-Chen so you wanna finish this up?

Got it, I’ll close this then. Thanks for the feedback!

Do you want to have a second attempt and try to do it the way I suggested?

Since the UI already knows when it's getting a prefix, how about you try to make it generate the correct links instead?

I think this the code in this PR already does this, I've been using this patch for a week, this is the HTML generated for the delete button

<form class="rm_form" action="/files/rm?path=/downloads" method="POST">
    <button type="submit" title="Delete">✗</button>
</form>

You can see that the path for the API is under the prefix /files/ but the path parameter has no prefix

So it seems the UI fix resolves the issue for normal users, but direct API calls (that include the prefix in the path) still fail.
Would you prefer we leave it as-is , or also handle such cases in the backend for consistency?

I think this issue is impossible to solve, the only way to make it work would be to accept both the paths with and without the prefix, but that would cause bigger issues, if the user had a file in the path /<prefix>/file.txt the command http://127.0.0.1:9999/<prefix>/rm?path=/<prefix>/file.txt would be ambiguous.

I think accepting the rm command without the prefix is the better option, that is what this PR already does

Thanks @svenstaro and @samu698 for the feedback!

I'm happy to try again. I’ll reopen the RP.

Please feel free to share any specific suggestions you’d like me to follow — I’d really appreciate the guidance.

I've updated the PR according to your suggestions. Thanks for the review!

Ok great! Do you want to add a test for this to make sure the behavior doesn't regress?

sure! I've added a test for the prefix stripping behavior.
Please let me know if anything else should be improved.

The Windows CI runner fails this test because creating symlinks requires admin privileges. Locally, when running with administrator rights, all tests pass. This issue also exists on master.