Lack of compatibility with reverse proxy #274

New Issue

Closed

opened 2026-01-19 18:29:42 +00:00 by michael · 10 comments

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

Owner

Copy Link

Originally created by @theAkito on GitHub.

I set up an nginx vhost to proxy the requests to the local transfer.sh instance. Therefore, I have to designate localhost:port as the listener for requests to transfer.sh. (Btw. the documentation is horribly wrong, one aspect is that you actually have to provide the full address not only the port, when specifying port arguments.)
The problem now is that when I upload a file, it responds with a link containing the localhost:port/wa3tr/test.txt URL instead of the one my reverse proxy listens to. I don't see a way to tell transfer.sh, that it should output a different URL, even if it listens on something entirely different.

All I need is the possibility to override the default output after a file has been uploaded.

Originally created by @theAkito on GitHub. I set up an nginx vhost to proxy the requests to the local transfer.sh instance. Therefore, I have to designate localhost:port as the listener for requests to transfer.sh. (Btw. the documentation is horribly wrong, one aspect is that you actually have to provide the _full address_ not only the port, when specifying port arguments.) The problem now is that when I upload a file, it responds with a link containing the `localhost:port/wa3tr/test.txt` URL instead of the one my reverse proxy listens to. I don't see a way to tell transfer.sh, that it should output a different URL, even if it listens on something entirely different. All I need is the possibility to override the default output after a file has been uploaded.

michael closed this issue 2026-01-19 18:29:42 +00:00

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

Author

Owner

Copy Link

@paolafrancesca commented on GitHub:

—proxy-path should be a path, not a domain
so if you are proxing from http://yourdomin.com/apath to transfer.sh bound on localhost:8080 you should pass —proxy-path apath and set your proxy to erite as host header yourdomain.com

I may have misspelled the number of dashes required for the param to be accepted

Il giorno 30 mar 2019, alle ore 13:35, Akito13 notifications@github.com ha scritto:

@aspacca First of all, thank you for your quick response and action.

I checked out to ISSUE-203 but I get

flag provided but not defined: -proxy-path
when providing

--proxy-path domain.dom
It removes the first dash.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@paolafrancesca commented on GitHub: —proxy-path should be a path, not a domain so if you are proxing from http://yourdomin.com/apath to transfer.sh bound on localhost:8080 you should pass —proxy-path apath and set your proxy to erite as host header yourdomain.com I may have misspelled the number of dashes required for the param to be accepted > Il giorno 30 mar 2019, alle ore 13:35, Akito13 <notifications@github.com> ha scritto: > > @aspacca First of all, thank you for your quick response and action. > > I checked out to ISSUE-203 but I get > > flag provided but not defined: -proxy-path > when providing > > --proxy-path domain.dom > It removes the first dash. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

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

Author

Owner

Copy Link

@paolafrancesca commented on GitHub:

sorry @Akito13 , wrong issue

as for the proxy support, there are actually two problem: one is the path and one is the host
the path issue in solved in #206 (please, note that a new param --proxy-path is needed to instruct transfer.sh to build the proper redirect url), I ask you to test that branch

as for the host issue: you have to instruct your proxy to rewrite the host header with the original one, instead of overwriting with the one to the proxied service
on nginx you can achieve this with proxy_set_header Host $host;

@paolafrancesca commented on GitHub: sorry @Akito13 , wrong issue as for the proxy support, there are actually two problem: one is the path and one is the host the path issue in solved in #206 (please, note that a new param --proxy-path is needed to instruct transfer.sh to build the proper redirect url), I ask you to test that branch as for the host issue: you have to instruct your proxy to rewrite the host header with the original one, instead of overwriting with the one to the proxied service on nginx you can achieve this with `proxy_set_header Host $host;`

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

Author

Owner

Copy Link

@theAkito commented on GitHub:

@aspacca First of all, thank you for your quick response and action.

I checked out to ISSUE-203 but I get

flag provided but not defined: -proxy-path

when providing

--proxy-path domain.dom

It removes the first dash.

@theAkito commented on GitHub: @aspacca First of all, thank you for your quick response and action. I checked out to ISSUE-203 but I get ``` flag provided but not defined: -proxy-path ``` when providing ``` --proxy-path domain.dom ``` It removes the first dash.

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

Author

Owner

Copy Link

@paolafrancesca commented on GitHub:

then you don't need --proxy-path param bust just to instruct your proxy to set the host header as the same as the domain of the proxy
as I wrote before on nginx you can achieve this with proxy_set_header Host $host;

@paolafrancesca commented on GitHub: then you don't need `--proxy-path` param bust just to instruct your proxy to set the host header as the same as the domain of the proxy as I wrote before on nginx you can achieve this with `proxy_set_header Host $host;`

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

Author

Owner

Copy Link

@theAkito commented on GitHub:

—proxy-path should be a path, not a domain so if you are proxing from http://yourdomin.com/apath to transfer.sh bound on localhost:8080 you should pass —proxy-path apath and set your proxy to erite as host header yourdomain.com I may have misspelled the number of dashes required for the param to be accepted
…
Il giorno 30 mar 2019, alle ore 13:35, Akito13 @.***> ha scritto: @aspacca First of all, thank you for your quick response and action. I checked out to ISSUE-203 but I get flag provided but not defined: -proxy-path when providing --proxy-path domain.dom It removes the first dash. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

I don't use a path, I use the root directive. I just need my actual domain to be shown in the output after uploading a file and if possible change the UI as well, as this is also flooded with localhosts.

@theAkito commented on GitHub: > > —proxy-path should be a path, not a domain so if you are proxing from http://yourdomin.com/apath to transfer.sh bound on localhost:8080 you should pass —proxy-path apath and set your proxy to erite as host header yourdomain.com I may have misspelled the number of dashes required for the param to be accepted > […](#) > Il giorno 30 mar 2019, alle ore 13:35, Akito13 ***@***.***> ha scritto: @aspacca First of all, thank you for your quick response and action. I checked out to ISSUE-203 but I get flag provided but not defined: -proxy-path when providing --proxy-path domain.dom It removes the first dash. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread. I don't use a path, I use the root directive. I just need my actual domain to be shown in the output after uploading a file and if possible change the UI as well, as this is also flooded with localhosts.

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

Author

Owner

Copy Link

@theAkito commented on GitHub:

then you don't need --proxy-path param bust just to instruct your proxy to set the host header as the same as the domain of the proxy
as I wrote before on nginx you can achieve this with proxy_set_header Host $host;

Even if this solves the problem partially, transfer.sh still thinks that it uses the localhost as a destination address, which also implies that when you visit mydomain.com where transfer.sh is hosted, then it shows all the links as localhost on the transfer.sh Web UI.

It'd be excellent, if there was a param like --proxy-address which replaces all visible output of transfer.sh links, while keeping the actual localhost in the background, but invisible to the outside.

@theAkito commented on GitHub: > > > then you don't need `--proxy-path` param bust just to instruct your proxy to set the host header as the same as the domain of the proxy > as I wrote before on nginx you can achieve this with `proxy_set_header Host $host;` Even if this solves the problem partially, transfer.sh still thinks that it uses the localhost as a destination address, which also implies that when you visit mydomain.com where transfer.sh is hosted, then it shows all the links as localhost on the transfer.sh Web UI. It'd be excellent, if there was a param like `--proxy-address` which replaces all visible output of transfer.sh links, while keeping the actual localhost in the background, but invisible to the outside.

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

Author

Owner

Copy Link

@paolafrancesca commented on GitHub:

transfer.sh supported proxy host rewriting since before I became maintainer of the project.
I use exactly in a proxy configuration with nginx and the url generated are correct.
All the links in UI are relative, so they doesn't contain the host part
As for the the urls generated by the backend, they come from the request done to the service: if the host header is set to the one of the front proxy than the url generated will have the host of the front proxy. There's no need for a --proxy-address flag.
I think you have some misconfiguration in your proxy setup.
What software do you use? What's the configuration?

@paolafrancesca commented on GitHub: transfer.sh supported proxy host rewriting since before I became maintainer of the project. I use exactly in a proxy configuration with nginx and the url generated are correct. All the links in UI are relative, so they doesn't contain the host part As for the the urls generated by the backend, they come from the request done to the service: if the host header is set to the one of the front proxy than the url generated will have the host of the front proxy. There's no need for a `--proxy-address` flag. I think you have some misconfiguration in your proxy setup. What software do you use? What's the configuration?

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

Author

Owner

Copy Link

@theAkito commented on GitHub:

@aspacca Indeed, setting proxy_set_header Host $host; within my vhost file helped. The only problems remaining are

1. It prints http://mydomain.com/qwert/filename.txt instead of https://mydomain.com/qwert/filename.txt.
2. It prints it like

username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt
http://mydomain.com/qwert/filename.txtusername@hostname:~$

instead of

username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt
http://mydomain.com/qwert/filename.txt
username@hostname:~$

and finally, instead of

username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt
https://mydomain.com/qwert/filename.txt
username@hostname:~$

@theAkito commented on GitHub: @aspacca Indeed, setting `proxy_set_header Host $host;` within my vhost file helped. The only problems remaining are 1. It prints `http://mydomain.com/qwert/filename.txt` instead of `https://mydomain.com/qwert/filename.txt`. 2. It prints it like ``` username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt http://mydomain.com/qwert/filename.txtusername@hostname:~$ ``` instead of ``` username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt http://mydomain.com/qwert/filename.txt username@hostname:~$ ``` and finally, instead of ``` username@hostname:~$ curl --upload-file filename.txt https://mydomain.com/filename.txt https://mydomain.com/qwert/filename.txt username@hostname:~$ ```

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

Author

Owner

Copy Link

@paolafrancesca commented on GitHub:

@Akito13
pass this params to transfer.sh

--tls-listener (whatever you have now as listener)
--tls-listener-only
--tls-cert-file (path to the cert.pem used on the proxy)
--tls-private-key (path to the privkey.pem used on the proxy)

As for the missing newline, it is intended behaviour wanted by @nl5887, you can use the following if you need the newline:
curl -s --upload-file filename.txt https://mydomain.com/filename.txt | xargs echo

@paolafrancesca commented on GitHub: @Akito13 pass this params to transfer.sh ``` --tls-listener (whatever you have now as listener) --tls-listener-only --tls-cert-file (path to the cert.pem used on the proxy) --tls-private-key (path to the privkey.pem used on the proxy) ``` As for the missing newline, it is intended behaviour wanted by @nl5887, you can use the following if you need the newline: `curl -s --upload-file filename.txt https://mydomain.com/filename.txt | xargs echo`

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

Author

Owner

Copy Link

@theAkito commented on GitHub:

| xargs echo

Well, so this part breaks it for me, anyway. I decided to create a modified version of the transfer() function to fix the https and echo issue. Now, if I remove only the the https issue, there is still the unfixable echo issue, as the lack of new line is intentional. So, I have to rely on transfer() anyway, which means I might as well solve the https issue using the function, as well.

Here is my function:

transfer(){
if [ $# -eq 0 ]; then
    echo -e "No arguments specified.\nUsage:\n  transfer <file|directory>\n  ... | transfer <file_name>">&2;
    return 1;
fi;
if tty -s; then
    file="$1";
    file_name=$(basename "$file");
if [ ! -e "$file" ]; then
    echo -e "$file: No such file or directory" >&2;
    return 1;
fi;
if [ -d "$file" ]; then
    file_name="$file_name.zip" ,;
    (cd "$file" && zip -r -q - .) | curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o;
else
    cat "$file" | curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o;
fi;
else
    file_name=$1;
    curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o;
fi;
}

So far, I thank you for your help, I appreciate it. The original issue is now solved, so I will close this.

Just one last thing: is it easy to add the new line output to my fork of transfer.sh? I unfortunately don't know what I would need to edit to achieve that. If it is easy for you to tell me, it would be nice of you to do that.

@theAkito commented on GitHub: > > ` | xargs echo` Well, so this part breaks it for me, anyway. I decided to create a modified version of the `transfer()` function to fix the `https` and `echo` issue. Now, if I remove only the the `https` issue, there is still the unfixable `echo` issue, as the lack of new line is intentional. So, I have to rely on `transfer()` anyway, which means I might as well solve the `https` issue using the function, as well. Here is my function: ``` transfer(){ if [ $# -eq 0 ]; then echo -e "No arguments specified.\nUsage:\n transfer <file|directory>\n ... | transfer <file_name>">&2; return 1; fi; if tty -s; then file="$1"; file_name=$(basename "$file"); if [ ! -e "$file" ]; then echo -e "$file: No such file or directory" >&2; return 1; fi; if [ -d "$file" ]; then file_name="$file_name.zip" ,; (cd "$file" && zip -r -q - .) | curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o; else cat "$file" | curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o; fi; else file_name=$1; curl --upload-file "-" "https://my.domain.com/$file_name" 2>/dev/null > o && sed -i 's/http/https/g' o && echo | cat o - && rm o; fi; } ``` So far, I thank you for your help, I appreciate it. The original issue is now solved, so I will close this. Just one last thing: is it easy to add the new line output to my fork of transfer.sh? I unfortunately don't know what I would need to edit to achieve that. If it is easy for you to tell me, it would be nice of you to do that.

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dependabot/go_modules/golang.org/x/crypto-0.45.0

dependabot/go_modules/golang.org/x/net-0.38.0

revert-646-main

dependabot/go_modules/golang.org/x/oauth2-0.27.0

check-ci-20241026

aspacca-patch-1

seed-rand

fix-basic-auth

fix-header-map-change-after-writeheader-call

issue-503

issue-487

gpg-encryption-support

lint-accept-range

bump-min-go-version-and-include-tip

accept-range

local-google-fonts

parallel-range-requests

issue-485

sb/storj-bump

fix-perform-clamav-prescan

revert-389-clamav-prescan

clamav-prescan

changes-in-front-end

ISSUE-440

revert-422-main

master

golint

ISSUE-398

multiple-fixes

ISSUE-382-take2

ISSUE-382

fix-workflows

fixes-20210521

ISSUE-371

ISSUE-38-WEB

ISSUE-313

ISSUE-296

fuzz

BINARY-RELEASES

ISSUE-256

v1.6.1

v1.6.0

v1.5.0

v1.4.0

v1.3.1

v1.3.0

v1.2.6

v1.2.4

v1.2.3

v1.2.2

v1.2.1

v1.2.0

v1.1.7

v1.1.6

v1.1.5

v1.1.4

v1.1.3

v1.1.2

v1.1.1

v1.1.0

v1.0.0

Labels

Clear labels

bug

docker

enhancement

hacktoberfest

help wanted

invalid

question

storage provider

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

michael

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#274