[GH-ISSUE #553] Changing the behaviour of the refresh parameter #199

New issue

Closed

opened 2026-02-25 22:34:36 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 22:34:36 +03:00

Owner

Originally created by @vikobeibe on GitHub (Dec 4, 2024).
Original GitHub issue: https://github.com/flyimg/flyimg/issues/553

Originally assigned to: @sadok-f on GitHub.

Is your feature request related to a problem? Please describe.
This is not related to a problem. It is rather a suggestion that might enhance the usage of the rf_1 parameter which is used to fetch a fresh copy of the original image from the source.

Describe the solution you'd like
Currently when rf_1 is passed, Flyimg will attempt to fetch the original image from the source and if successful, the existing version in /var/tmp will be replaced with the new one. If the request is not successful, a HTTP error code will be returned and the existing original version will continue to be served when requested. This is very useful for requests that the source of the image has failed to respond to, for exmaple HTTP5xx errors. However, when the source has responded with HTTP 404, this means the image might have been deleted. Flyimg should then delete the original from /var/tmp/ instead of keeping and serving it. This most probably holds true for the processed variants as well, a.k.a the output cache.

Describe alternatives you've considered
An alternative to altering the rf_1 behaviour to avoid adding complexity is to introduce a new parameter that deletes both the original and the outputs, for example del_1.

Additional context
Web proxies should not serve copies of content that is no longer available at the source, since the content is likely to have been removed intentionally. At the same time, when the source returns a server error, it is perfectly valid to continue serving the content from cache, which is also known as stale response.

Originally created by @vikobeibe on GitHub (Dec 4, 2024). Original GitHub issue: https://github.com/flyimg/flyimg/issues/553 Originally assigned to: @sadok-f on GitHub. **Is your feature request related to a problem? Please describe.** This is not related to a problem. It is rather a suggestion that might enhance the usage of the `rf_1` parameter which is used to fetch a fresh copy of the original image from the source. **Describe the solution you'd like** Currently when `rf_1` is passed, Flyimg will attempt to fetch the original image from the source and if successful, the existing version in /var/tmp will be replaced with the new one. If the request is not successful, a HTTP error code will be returned and the existing original version will continue to be served when requested. This is very useful for requests that the source of the image has failed to respond to, for exmaple HTTP5xx errors. However, when the source has responded with HTTP 404, this means the image might have been deleted. Flyimg should then delete the original from /var/tmp/ instead of keeping and serving it. This most probably holds true for the processed variants as well, a.k.a the output cache. **Describe alternatives you've considered** An alternative to altering the `rf_1` behaviour to avoid adding complexity is to introduce a new parameter that deletes both the original and the outputs, for example `del_1`. **Additional context** Web proxies should not serve copies of content that is no longer available at the source, since the content is likely to have been removed intentionally. At the same time, when the source returns a server error, it is perfectly valid to continue serving the content from cache, which is also known as `stale` response.

kerem

2026-02-25 22:34:36 +03:00

closed this issue
added the
enhancement

stale
labels

kerem commented

2026-02-25 22:34:36 +03:00

Author

Owner

@sadok-f commented on GitHub (Dec 11, 2024):

Thank you @vikobeibe for this feature request and sorry for my late response.
I'm not sure if you're aware of the crown job that purges the /var/tmp folder which is enabled by default, many users suggested this feature to reduce the container size, especially after heavy usage.
so I 'm not sure if I understand correctly your use case, but if you setup the cronjob to delete the tmp folder and use the rf_1 option, does this solve your issue?
or do you want explicitly to remove the downloaded image and the generated one using a new del_1 option?

@sadok-f commented on GitHub (Dec 11, 2024): Thank you @vikobeibe for this feature request and sorry for my late response. I'm not sure if you're aware of the crown job that purges the /var/tmp folder which is enabled by default, many users suggested this feature to reduce the container size, especially after heavy usage. so I 'm not sure if I understand correctly your use case, but if you setup the cronjob to delete the tmp folder and use the `rf_1` option, does this solve your issue? or do you want explicitly to remove the downloaded image and the generated one using a new `del_1` option?

kerem commented

2026-02-25 22:34:36 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 11, 2025):

This issue is stale (30 days with no activity)

@github-actions[bot] commented on GitHub (Jan 11, 2025): This issue is stale (30 days with no activity)

kerem commented

2026-02-25 22:34:36 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Jan 26, 2025):

This issue was closed (14 days since being marked as stale)

@github-actions[bot] commented on GitHub (Jan 26, 2025): This issue was closed (14 days since being marked as stale)

kerem referenced this issue

2026-03-15 15:05:46 +03:00

[GH-ISSUE #199] Separate Auto Lossy and Lossless #697