Support for customized subroute? #276

New Issue

michael · 2026-01-19T18:29:42Z

michael commented

2026-01-19 18:29:42 +00:00

Originally created by @lucernae on GitHub.

Hi! Love this work, @dutchcoders !
Transfer.sh is very easy to deploy and try.

I have some questions on this.
We are planning to use transfer.sh in our web apps as a subroute, in a sense like this:

Let's say I deployed a web app with domain: domain.org, and accessible in this url http://domain.org/.
I would like to deploy transfer.sh in a subroute (because the web apps is a separate system), like this:
http://domain.org/transfer to acces transfer.sh.

I tried to reroute the traffic using haproxy, but it seems the html inside is bound to the route url. So to summarize, I have broken links for scripts, styles, etc, because it gives links to http://domain.org/scripts instead of http://domain.org/transfer/scripts.

So, my question is, does this use case currently handled by transfer.sh?
If not, should I make PR to do that (I'm not too familiar with golang, so it might take time)?

Originally created by @lucernae on GitHub. Hi! Love this work, @dutchcoders ! Transfer.sh is very easy to deploy and try. I have some questions on this. We are planning to use transfer.sh in our web apps as a subroute, in a sense like this: Let's say I deployed a web app with domain: `domain.org`, and accessible in this url `http://domain.org/`. I would like to deploy transfer.sh in a subroute (because the web apps is a separate system), like this: `http://domain.org/transfer` to acces transfer.sh. I tried to reroute the traffic using haproxy, but it seems the html inside is bound to the route url. So to summarize, I have broken links for scripts, styles, etc, because it gives links to `http://domain.org/scripts` instead of `http://domain.org/transfer/scripts`. So, my question is, does this use case currently handled by transfer.sh? If not, should I make PR to do that (I'm not too familiar with golang, so it might take time)?

michael closed this issue

2026-01-19 18:29:42 +00:00

michael commented

2026-01-19 18:29:42 +00:00

@lucernae commented on GitHub:

Also, @aspacca are you the maintainer of this project now?

@lucernae commented on GitHub: Also, @aspacca are you the maintainer of this project now?

michael commented

2026-01-19 18:29:42 +00:00

@paolafrancesca commented on GitHub:

hello @lucernae you're right
please test #206 branch and tell me if it fixes the problem
I tested only on UI side and it works

please, note that a new param --proxy-path is needed to instruct transfer.sh to build the proper redirect url

@paolafrancesca commented on GitHub: hello @lucernae you're right please test #206 branch and tell me if it fixes the problem I tested only on UI side and it works please, note that a new param --proxy-path is needed to instruct transfer.sh to build the proper redirect url

michael commented

2026-01-19 18:29:42 +00:00

@lucernae commented on GitHub:

Thanks, for the quick follow up!
I ended up doing some modification (of course it's a hack :p), to make transfer.sh web shows the correct url and all the styles.
I'm not too confident with the code anyway, so I will test your branch code.
It's interesting to see the problem in issue #204 too since it was dealing with https terminated in the proxy.
I will check your branch with the X-Forwarded-Proto header set for https.

@lucernae commented on GitHub: Thanks, for the quick follow up! I ended up doing some modification (of course it's a hack :p), to make transfer.sh web shows the correct url and all the styles. I'm not too confident with the code anyway, so I will test your branch code. It's interesting to see the problem in issue #204 too since it was dealing with https terminated in the proxy. I will check your branch with the X-Forwarded-Proto header set for https.

michael commented

2026-01-19 18:29:42 +00:00

@paolafrancesca commented on GitHub:

@lucernae I started implementing #206 (and related branch in transfer.sh-web) trying to avoid to pass an explicit param for the proxy path and relying instead on relative paths and request rewriting in the proxy, until I realized I needed it to generate the download url: if it'd still find a way to do without it I'd prefer

I use nginx as proxy, and in my tests with subpath I made the equivalent configuration you did with haproxy removing the subpath when proxying to transfer.sh backend

the basic difference between our solutions is that I use the param only for build the output urls (in the frontend template and in the curl output, as long as for the X-Delete-Url header), while you use it everywhere. The less usage we have in general the less maintenance we need, so I'd go with my solution :)

I indeed forgot about {{.WebAddress}}, it is an easy fix and I will do. As for the link in the preview page that's strange: that's the reason why I added the param at all, to be able to build the url, I will check again what I missed and fix

The navigation issue was a deliberate choice for the link to {{.Hostname}}, since it would be the correct one, but I missed the home link and it can be solved with a relative url as well (having, as for the rest, two different versions of the included file: one for the download page and one for the index - this may be refactored back to a single file with some light logic in the template)

as for the last question: yes, I became maintainer of the project on July 2018 ca.

@paolafrancesca commented on GitHub: @lucernae I started implementing #206 (and related branch in transfer.sh-web) trying to avoid to pass an explicit param for the proxy path and relying instead on relative paths and request rewriting in the proxy, until I realized I needed it to generate the download url: if it'd still find a way to do without it I'd prefer I use nginx as proxy, and in my tests with subpath I made the equivalent configuration you did with haproxy removing the subpath when proxying to transfer.sh backend the basic difference between our solutions is that I use the param only for build the output urls (in the frontend template and in the curl output, as long as for the `X-Delete-Url` header), while you use it everywhere. The less usage we have in general the less maintenance we need, so I'd go with my solution :) I indeed forgot about `{{.WebAddress}}`, it is an easy fix and I will do. As for the link in the preview page that's strange: that's the reason why I added the param at all, to be able to build the url, I will check again what I missed and fix The navigation issue was a deliberate choice for the link to `{{.Hostname}}`, since it would be the correct one, but I missed the `home` link and it can be solved with a relative url as well (having, as for the rest, two different versions of the included file: one for the download page and one for the index - this may be refactored back to a single file with some light logic in the template) as for the last question: yes, I became maintainer of the project on July 2018 ca.

michael commented

2026-01-19 18:29:42 +00:00

@lucernae commented on GitHub:

I did some quick testing on my part:
Let's say, I deployed on http://domain.org/transfer using a combination of haproxy docker container and transfer.sh (go binary).

docker-compose.yml:

version: '2'
services:
  transfer:
    image: haproxy:latest
    volumes:
      - ./haproxy:/usr/local/etc/haproxy:ro
    ports:
      - "80:80"

haproxy.cfg:
I test using http mode for now. Because there are still some issues.

global
daemon

frontend 80
bind *:80
mode http
acl transfer_path path_sub -i /transfer
use_backend transfer if transfer_path

backend transfer
acl forwarded_proto hdr_cnt(X-Forwarded-Proto) eq 0
acl forwarded_port hdr_cnt(X-Forwarded-Port) eq 0
http-request add-header X-Forwarded-Port %[dst_port] if forwarded_port
mode http
reqirep ^([^\ :]*)\ /transfer/(.*) \1\ /\2
server transfer transfer.test:8111

The last section of backend with regirep line is basically me trying to remove /transfer proxy-path. Because it turns out, internally, transfer.sh is serving the index page without the proxy-path (directly after domain name).
The domain name I used here: transfer.test is actually resolved to my computer ipaddress

transfer.sh run config:

./transfer.sh --provider local --basedir /my-download-folder --listener 0.0.0.0:8111 --proxy-path transfer

What I test:

Scripts, styles, images, now resolved correctly from the base url. The internal html pages now uses relative url, maybe that's why.
Upload works, and it returns the correct preview page, e.g. http://domain.org/transfer/xxxxx/somefile.txt
Download link from preview page is broken. I checked the code, maybe because {{.Url}} var was not prepended by s.proxyPath prefix in previewHandler.
I tried downloading directly by curl, it works.
All the relevant links in the sample page (index page) doesn't have proxy-path prepended on the url. If user read this sample and try to upload from command line, it will not work. I suggest, maybe you could change resolveWebAddress to include proxy-path? So that every {{.webAddress}} on the index page will contain this (I'm not sure where else the variable get used, so it may affect other things).
Navigating from preview page back to index page by clicking homepage link leads to a broken url, because it is linked to the root url /. Similar with above problem, maybe it can be fixed by linking it to webAddress instead.

I think that's all for now.
I mentioned that I ended up doing some modification on my own fork, but not too confident with my code. If you're interested with it, you can check:
https://github.com/kartoza/transfer.sh/tree/add_baseurl
and
https://github.com/kartoza/transfer.sh-web/tree/add_baseurl
I ended up with a slightly different approach.
In that branch, I tried to make transfer.sh serve everything from web-base-url (in your branch, you name it proxy-path). If I run this go binary directly the index page is located in http://domain.org/transfer without having to modify the url in haproxy using regirep.
It might not be the best way to do this, but at least it might give you an idea of what I'm trying to do :)

@lucernae commented on GitHub: I did some quick testing on my part: Let's say, I deployed on `http://domain.org/transfer` using a combination of haproxy docker container and transfer.sh (go binary). docker-compose.yml: ``` version: '2' services: transfer: image: haproxy:latest volumes: - ./haproxy:/usr/local/etc/haproxy:ro ports: - "80:80" ``` haproxy.cfg: I test using http mode for now. Because there are still some issues. ``` global daemon frontend 80 bind *:80 mode http acl transfer_path path_sub -i /transfer use_backend transfer if transfer_path backend transfer acl forwarded_proto hdr_cnt(X-Forwarded-Proto) eq 0 acl forwarded_port hdr_cnt(X-Forwarded-Port) eq 0 http-request add-header X-Forwarded-Port %[dst_port] if forwarded_port mode http reqirep ^([^\ :]*)\ /transfer/(.*) \1\ /\2 server transfer transfer.test:8111 ``` The last section of backend with regirep line is basically me trying to remove `/transfer` proxy-path. Because it turns out, internally, transfer.sh is serving the index page without the proxy-path (directly after domain name). The domain name I used here: transfer.test is actually resolved to my computer ipaddress transfer.sh run config: ``` ./transfer.sh --provider local --basedir /my-download-folder --listener 0.0.0.0:8111 --proxy-path transfer ``` What I test: - [x] Scripts, styles, images, now resolved correctly from the base url. The internal html pages now uses relative url, maybe that's why. - [x] Upload works, and it returns the correct preview page, e.g. `http://domain.org/transfer/xxxxx/somefile.txt` - [ ] Download link from preview page is broken. I checked the code, maybe because `{{.Url}}` var was not prepended by `s.proxyPath` prefix in `previewHandler`. - [x] I tried downloading directly by curl, it works. - [ ] All the relevant links in the sample page (index page) doesn't have `proxy-path` prepended on the url. If user read this sample and try to upload from command line, it will not work. I suggest, maybe you could change `resolveWebAddress` to include proxy-path? So that every `{{.webAddress}}` on the index page will contain this (I'm not sure where else the variable get used, so it may affect other things). - [ ] Navigating from preview page back to index page by clicking `homepage` link leads to a broken url, because it is linked to the root url `/`. Similar with above problem, maybe it can be fixed by linking it to `webAddress` instead. I think that's all for now. I mentioned that I ended up doing some modification on my own fork, but not too confident with my code. If you're interested with it, you can check: https://github.com/kartoza/transfer.sh/tree/add_baseurl and https://github.com/kartoza/transfer.sh-web/tree/add_baseurl I ended up with a slightly different approach. In that branch, I tried to make transfer.sh serve everything from `web-base-url` (in your branch, you name it `proxy-path`). If I run this go binary directly the index page is located in `http://domain.org/transfer` without having to modify the url in haproxy using regirep. It might not be the best way to do this, but at least it might give you an idea of what I'm trying to do :)

michael commented

2026-01-19 18:29:42 +00:00

@lucernae commented on GitHub:

@aspacca

the basic difference between our solutions is that I use the param only for build the output urls (in the frontend template and in the curl output, as long as for the X-Delete-Url header), while you use it everywhere. The less usage we have in general the less maintenance we need, so I'd go with my solution :)

I was also going for relative URL first because it makes less change, but stumbled upon that download link. But I don't mind with any solutions, less change is better! :). I can accomodate easily with haproxy to modify the target URL.

Thanks for the help. Feel free to ping me again to test the update :).

@lucernae commented on GitHub: @aspacca > the basic difference between our solutions is that I use the param only for build the output urls (in the frontend template and in the curl output, as long as for the X-Delete-Url header), while you use it everywhere. The less usage we have in general the less maintenance we need, so I'd go with my solution :) I was also going for relative URL first because it makes less change, but stumbled upon that download link. But I don't mind with any solutions, less change is better! :). I can accomodate easily with haproxy to modify the target URL. Thanks for the help. Feel free to ping me again to test the update :).

michael commented

2026-01-19 18:29:42 +00:00

@lucernae commented on GitHub:

Thanks @aspacca I will test that tomorrow.

@lucernae commented on GitHub: Thanks @aspacca I will test that tomorrow.

michael commented

2026-01-19 18:29:42 +00:00

@paolafrancesca commented on GitHub:

@lucernae any feedback?

@paolafrancesca commented on GitHub: @lucernae any feedback?

michael commented

2026-01-19 18:29:42 +00:00

@paolafrancesca commented on GitHub:

@lucernae I should have fixed everything you reported in the branch for the issue
also handling proxy path in tar/gz/zip handlers

@paolafrancesca commented on GitHub: @lucernae I should have fixed everything you reported in the branch for the issue also handling proxy path in tar/gz/zip handlers

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#276