Feature request: ability to set a default Max-Downloads and Max-Days #80

New Issue

michael · 2026-01-19T18:28:52Z

michael commented

2026-01-19 18:28:52 +00:00

Originally created by @danfinn on GitHub.

For my use case it would be really useful if it was possible to set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible?

Originally created by @danfinn on GitHub. For my use case it would be really useful if it was possible to set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible?

michael commented

2026-01-19 18:28:53 +00:00

@paolafrancesca commented on GitHub:

@danfinn

set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible

it seems something that's more related to the client side of the request
how do you upload the files in first place? a shell alias won't be sufficient for that?

@paolafrancesca commented on GitHub: @danfinn > set a default for Max-Downloads and Max-Days so that it doesn't have to be specified with every upload. Is this possible it seems something that's more related to the client side of the request how do you upload the files in first place? a shell alias won't be sufficient for that?

michael commented

2026-01-19 18:28:53 +00:00

@danfinn commented on GitHub:

Hi @aspacca this would be for self hosted. I suppose that would work for a default setting of Max-Days, what I'm more interested in is a default setting for Max-Downloads.

@danfinn commented on GitHub: Hi @aspacca this would be for self hosted. I suppose that would work for a default setting of Max-Days, what I'm more interested in is a default setting for Max-Downloads.

michael commented

2026-01-19 18:28:53 +00:00

@danfinn commented on GitHub:

Setting it on the client side allows people to change it or tweak it to set it to whatever they want. We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example.

@danfinn commented on GitHub: Setting it on the client side allows people to change it or tweak it to set it to whatever they want. We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example.

michael commented

2026-01-19 18:28:53 +00:00

@paolafrancesca commented on GitHub:

hello @danfinn

are you talking about a self-host instance of transfer.sh are you?

regarding a default Max-Days value set on the server side, this is the equivalent of setting purge-days (ie: number of days after the uploads are purged automatically)

@paolafrancesca commented on GitHub: hello @danfinn are you talking about a self-host instance of transfer.sh are you? regarding a default `Max-Days` value set on the server side, this is the equivalent of setting `purge-days` (ie: number of days after the uploads are purged automatically)

michael commented

2026-01-19 18:28:53 +00:00

@paolafrancesca commented on GitHub:

We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example.

if we are talking about Max-Days and the rention of the files on the server, you have purge-days for that

it a little more unclear to me what's the goal, server side, to set Max-Downloads, considering that will just prevent the file to be downloaded, but it will not remove the file from the server

@paolafrancesca commented on GitHub: > We would like the ability to force it (or at least set a default so that if it's not set by the client) to 1 day for example. if we are talking about `Max-Days` and the rention of the files on the server, you have `purge-days` for that it a little more unclear to me what's the goal, server side, to set `Max-Downloads`, considering that will just prevent the file to be downloaded, but it will not remove the file from the server

michael commented

2026-01-19 18:28:53 +00:00

@stefanbenten commented on GitHub:

I think having the possibility of enforcing Max-Download or Max-Days is neat, however i do agree that it would need some frontend changes to make users aware of it.
Does your use case need the Web Interface? @danfinn
If not, it would definitely make things easier and could be approached from the angle that there are users wanting to disable the web interface anyway. That would mean, we enable an API-only mode, with the ability to then enforce these settings?

@stefanbenten commented on GitHub: I think having the possibility of enforcing Max-Download or Max-Days is neat, however i do agree that it would need some frontend changes to make users aware of it. Does your use case need the Web Interface? @danfinn If not, it would definitely make things easier and could be approached from the angle that there are users wanting to disable the web interface anyway. That would mean, we enable an API-only mode, with the ability to then enforce these settings?

michael commented

2026-01-19 18:28:53 +00:00

@danfinn commented on GitHub:

Sorry, you are correct. I wasn't thinking correctly, it's been a while since I posted this. What we would really like is to be able to enforce a limit on downloads. Essentially we are looking for a secure place to upload a file that can only be downloaded once (or however many times we set in the config).

We would be using this in the same way we leverage another project called One Time Secret:
https://onetimesecret.com/

With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh.

@danfinn commented on GitHub: Sorry, you are correct. I wasn't thinking correctly, it's been a while since I posted this. What we would really like is to be able to enforce a limit on downloads. Essentially we are looking for a secure place to upload a file that can only be downloaded once (or however many times we set in the config). We would be using this in the same way we leverage another project called One Time Secret: https://onetimesecret.com/ With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh.

michael commented

2026-01-19 18:28:53 +00:00

@Martinligabue commented on GitHub:

I would add the use case of a small self-hosted server that doesn't have a lot of disk space, and having a hard time limit would help clean up old files.

Edit: I see there's the PURGE_DAYS envvar, so that already has a way to be solved, can the other problem be solved in the same way?

@Martinligabue commented on GitHub: I would add the use case of a small self-hosted server that doesn't have a lot of disk space, and having a hard time limit would help clean up old files. Edit: I see there's the PURGE_DAYS envvar, so that already has a way to be solved, can the other problem be solved in the same way?

michael commented

2026-01-19 18:28:53 +00:00

@paolafrancesca commented on GitHub:

With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh.

oki, got it

I'd suggest that if a Max-Download is set on the server side, it cannot be set/it is ignored if set on the client side.
and the fact that it's set on server side must be informed from the frontend: similarly like now you have the information about the purge time

@stefanbenten what do you think?

@paolafrancesca commented on GitHub: > With that you share a secret with someone but they can only see it once and then it's gone. We would like to be able to accomplish the same thing with file transfers using transfer.sh. oki, got it I'd suggest that if a `Max-Download` is set on the server side, it cannot be set/it is ignored if set on the client side. and the fact that it's set on server side must be informed from the frontend: similarly like now you have the information about the purge time @stefanbenten what do you think?

michael commented

2026-01-19 18:28:53 +00:00

@paolafrancesca commented on GitHub:

@Martinligabue , yes, you are right, PURGE_DAYS is the way to go to purge (doh!) old/stale files from the storage

beware that Max-Donwloads and Max-Days do not execute any deletion of the files: they just prevent them to be downloaded.

the case for @danfinn was to be able to force a Max-Downloads server side: I'm still a little bit skeptical about this

btw, @danfinn : if you have a proxy like nginx or similare in front of the service you can just add/rewrite the headers there

@paolafrancesca commented on GitHub: @Martinligabue , yes, you are right, `PURGE_DAYS` is the way to go to purge (doh!) old/stale files from the storage beware that `Max-Donwloads` and `Max-Days` do not execute any deletion of the files: they just prevent them to be downloaded. the case for @danfinn was to be able to force a `Max-Downloads` server side: I'm still a little bit skeptical about this btw, @danfinn : if you have a proxy like nginx or similare in front of the service you can just add/rewrite the headers there

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dutchcoders/transfer.sh#80