It was thus said that the Great Sean Conner once stated: > > And I have my "proof-of-concept" up at well. It's at > > gemini://gemini.conman.org/test/testcache.gemini I have removed this "proof-of-concept" after some thought about the approach. I agree with Ali Fardan that Mallick's method is the way to handle caching (or not at all). Now, on with destroying my own idea here ... > How it works: A plain request: > > gemini://gemini.conman.org/test/cachefile.txt > > will always return the content. However, if you include a timestamp using a > path parameter (which is *NOT* the same as a query paramter, and is in the > ISO-8601 format): > > gemini://gemini.conman.org/test/cachefile.txt;2020-11-08T00:00:00 > > If the file is *newer* than that timestamp, you get the normal response of > 20 and all the content; otherwise you get a response of 23 (with the normal > MIME type) and no content, meaning it hasn't changed since the given date. The major problem here is timezones. Time zone information is complicated, and from what I've seen, operating system specific (the C standard doesn't mention it; POSIX does it one way; Windows another) so that's a complication for both servers and clients. Also, does the concept apply to each path component? Or only the end? For example: gemini://gemini.conman.org/test;2020-11-08T00:00:00/cachefile.txt return 23 if the directory test hasn't changed, even if cachefile.txt has? Or is it ignored *unless* it's the last path component? My gut instinct is to say "last component" but it get messy: gemini://gemini.coman.org/test;2020-11-08T00:00:00 will result in a redirect (or should), but gemini://gemini.coman.org/test;2020-11-08T00:00:00/ won't. So, for these reasons, nah. I won't push this. -spc
---
Previous in thread (52 of 55): 🗣️ John Cowan (cowan (a) ccil.org)
Next in thread (54 of 55): 🗣️ John Cowan (cowan (a) ccil.org)