Location-based reverse proxying breaks uploading to shares (and other things)

[intelfx]

Describe the bug

Using path-based reverse proxying (i.e., --rp-loc) causes multiple issues and specifically breaks uploading into link-shared folders:

1. Paths in the file tree browser are prepended with the location prefix (e.g., /copy/ if --rp-loc=/copy).
2. When adding a share, the share source path is prepended with the location prefix again.
3. When trying to upload to a share, the target path still contains the location prefix.
4. Any actual attempt to upload a file into a share ends up with a share-mapping failed error:

   copyparty[2023898]: 17:27:38.414 100.64.141.24 6       POST /copy/shares/kr4niq164hot/ @*
   copyparty[2023898]: 17:27:38.414 100.64.141.24 6       POST len=646 type=utf-8 ip=100.64.141.24 user=* req='/copy/shares/kr4niq164hot/' json={'name': 'sr-tcgrfs18.zip', 'size': 12178088, 'lmod': 1746794594.565, 'life': 0, 'hash': '12 chunks'}
   copyparty[2023898]: 17:27:38.415 100.64.141.24 6       http500: share-mapping failed; req='shares/kr4niq164hot' dbv='files' vrem='shared' n1='/shares/kr4niq164hot/' n2='/files/shared/' purl='/copy/files/shared/', '/shares/kr4niq164hot'
   

To Reproduce

/etc/copyparty.d/main.conf

# not actually YAML but lets pretend:
# -*- mode: yaml -*-
# vim: ft=yaml:

[global]
  j: 0

  i: unix:777:/run/copyparty/copyparty.sock
  http-only
  rp-loc: /copy

  shr: /shares
  shr-db: ./shares.db # relative to cwd, /var/lib/copyparty
  shr-adm: foo
  use-fpool
  u2j: 4
  u2abort: 3

  e2d
  hist: ./hist # relative to cwd, /var/lib/copyparty
  dbpath: ./db # relative to cwd, /var/lib/copyparty

[accounts]
  foo: bar

[/public]
  /path/to/public
  accs:
    r: *
    rw: foo

[/files]
  /path/to/files
  accs:
    rw: foo

# same for /media, /torrents

Expected behavior

When location-based reverse-proxying is used, the location prefix is correctly stripped out from all elements of the UI and uploading to shares is usable.

Screenshots

1. Paths in the file tree browser are prepended with the location prefix:
   
2. When adding a share, the share source path is prepended with the location prefix:
   
3. When trying to upload to a share, the target path still contains the location prefix:
   
4. Eventually, the upload fails:
   

Server details (if you're NOT using docker/podman)

• server OS / version: 1.17.1

• what copyparty did you grab: Arch

• how you're running it: systemd service

• run copyparty with --version:

  copyparty v1.17.1 "mixtape.m3u" (2025-05-18)
    CPython v3.13.3 on Linux64  [GCC 14.2.1 20250207]
     sqlite 3.49.2*1 | jinja 3.1.5 | pyftpd (None) | tftp (None)
  

• copyparty arguments and/or config-file: see above

[9001]

thanks, I'll have this fixed by the next version 👍

[9001]

alright, fixed point 4 now, so should be all good.

the semantics get a bit fuzzy when it doesn't have the whole (sub)domain to itself, but the current behavior is what made the most sense in my head (plus it was the easiest / least messy way to pull it off). That does have some side-effects like you've mentioned,

point 1 -- this was a semi-conscious decision to make it easier to jump from copyparty to another service you're hosting, and it was also technically way easier than excluding the parent "folders". If you'd like to hide them, the best approach is currently to add a bit of custom css as suggested by #93 (comment) --

assuming you're proxying /qwe/asd to copyparty (in other words, two subfolders to remove), then the following gives a decent result:

#treeul>li>a,  /*Root*/
#treeul>li>ul>li>a,  /*qwe*/
#treeul>li>ul>li>ul>li>a,  /*asd*/
#treepar>li>a,  /*qwe*/
#treepar>li>ul>li>a  /*asd*/ {
  display: none;
}
#treeul {
  left: -4em;
}
#treepar {
  left: -2.8em;
}

as for point 2 and 3, this was to make everything match the URLs as close as possible, and shouldn't be causing any problems -- but let me know if it does :>