in fact, the URL is redirected and thus not marked as downloaded.
I did not look much into it but maybe we should use an extended file attribute on our cache files. We could put the status of a response ( the first line, e.g. "20 text/gemini") in an extended attribute. This is not universally supported but should work on linux on most filesystems (should be supported on macOS, on BSD, the story is more complicated, on Windows I'm not sure). This could be a solution to multiple different problems, redirects but also input requests or certificate requests. The python xattr library supports Linux and macOS (python 3.8+), if I have time, I'll try to look in to this a bit.
I believe it could be a lot easier: "simply" make a soft link when a direction is redirected.
So gemini/bbs.geminispace.org/s/Gemini/12578 should be a simple soft link to gemini/bbs.geminispace.org/s/Geminispace/12578
This would also allows to follow the redirection while offline and display the good URL/cache
What do you think?
You are right, that is the simpler solution. This comment was maybe on the wrong todo but this is were I had the idea. I think it could still be a solution for 1* and 6* status codes. In the symlink solution, what would we do when the page it redirects to is not reachable? Save both for syncing and not create the first file?
On 24 mai 23 08:00, ~twijg wrote:
You are right, that is the simpler solution. This comment was maybe on the wrong todo but this is were I had the idea. I think it could still be a solution for 1* and 6* status codes. In the symlink solution, what would we do when the page it redirects to is not reachable? Save both for syncing and not create the first file?
That’s a very good question. Maybe, the easier solution is to make dumb redirection. We create the redirection then we create the error in the target, exactly like it would have been done if accessing the target URL directly.
I don’t see any drawback with this approach. (I may miss something, of course)