- 20 May, 2022 9 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
- 28 Apr, 2022 1 commit
-
-
Nils Goroll authored
-
- 27 Apr, 2022 1 commit
-
-
Nils Goroll authored
-
- 12 Apr, 2022 2 commits
-
-
Nils Goroll authored
kick the expiry thread
-
Nils Goroll authored
-
- 01 Feb, 2022 2 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
this would lead to DELETEs being always responded to with a 404
-
- 31 Jan, 2022 2 commits
-
-
Nils Goroll authored
This does not make a difference for HTTP1, and as we only use HTTP1 backends, does not many any difference right now.
-
Nils Goroll authored
Uploading files larger than 4GB could lead to an infinite loop and client requests failing with 423 Locked forever.
-
- 18 Oct, 2021 3 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
- 01 Oct, 2021 5 commits
-
-
Nils Goroll authored
Use of http_ForceField() with the url is now banned.
-
Nils Goroll authored
vrt_null_blob was moved into varnishd and thus is only available when a vmod is dlopen'ed from varnishd. Provide an own implementation and make sure it is exported.
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
- 10 Sep, 2021 3 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
There was an inherent race between the expiry thread and other file deletions. We solve this by making clear that expiry owns the reference. When some user action requires deletion, expiry is set to "now" and the file is removed from the index. We use the srvref as a marker for index removal. After removal from the index, the file can not be found any longer, so gaining an srvref is not possible. When expiry is first to delete the file, the file is removed from the index and the ref is lost.
-
Nils Goroll authored
tus_file_shutdown() deletes all files. This could interfere with the exp thread if it expired a file at the same time. Solve this race by first stopping the exp thread, then deleting all files and then running final checks that exp is actually cleaned up.
-
- 09 Sep, 2021 12 commits
-
-
Nils Goroll authored
in tus_file_final_concat(), we needed to get an fcore reference while holding the srv lock for lookup. Thus the srv lock would be kept until the fcore could get locked. To avoid this situation, we add the option to also gain refcounts under the server mutex.
-
Nils Goroll authored
I need to consider making this a system wide setting
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
If, for some reason, an fcore lock could not get aquired, the expiry thread would keep the server locked until that file was available again. Avoid this situation with a trivial trylock and retry.
-
Nils Goroll authored
-
Nils Goroll authored
Keeping a local varaible and the struct response member with a pointer to the fcore was unnecessary complex and a possible cause for error. Now that holding a pointer is conceptually equal to holding a lock, we should really avoid the local variable. Also fixes an (unlikely) leaked lock for TUS_FINAL and method != POST
-
Nils Goroll authored
- move lock and unlock to tus_file.c - clear the fcore pointer argument when the lock is not acquired
-
Nils Goroll authored
If a GET arrived before a file was complete, we would miss to unlock it due to the fcore pointer missing in the response struct.
-
Nils Goroll authored
-
Nils Goroll authored
-